cvs commit: src/usr.bin/kdump kdump.c

[Robert Watson]

On Sat, 6 Jan 2007, Peter Jeremy wrote:

> On Fri, 2007-Jan-05 16:07:58 -0500, John Baldwin wrote:
>> On Friday 05 January 2007 16:04, John Baldwin wrote:
>>> jhb         2007-01-05 21:04:37 UTC
>>>
>>>   FreeBSD src repository
>>>
>>>   Modified files:
>>>     usr.bin/kdump        kdump.c
>>>   Log:
>>>   Add code to parse the utrace(2) entries generated by malloc(3) in a more
>>>   human-readable format.  Note that we report 'realloc(p, 0)' as 'free(p)'
>>>   since both cases are encoded the same way and 'free()' is more common
>>>   than a realloc() to 0.
>>>
>>>   MFC after:      1 week
>
> This is much nicer than having to run kdump output thru my perl script to do 
> this.  The only downside I see is that the code in kdump assumes that any 
> utrace records that are sizeof(struct utrace_malloc) are generated by 
> malloc.  This isn't necessarily true - whilst nothing in the base system 
> apart from malloc currently uses utrace, it's possible that people are using 
> utrace in their own code.  I'd prefer to see this decoding controlled by a 
> command line option.  (Ideally, kdump would grow a configuration file so 
> that a user could define their own decoding rules - but that is a lot of 
> work).

Would it make sense to take this opportunity to require that utrace records 
begin with a 32-bit integer that defines what subsystem they are from, and 
allocate a subsystem namespace?  Or something along these lines?  It's easy to 
imagine other subsystems growing utrace support in user space, and wanting to 
use more than one at once.  I don't really mind what the mechanism is, but if 
we're going to add one, now is probably the time to do it, before kdump learns 
too much more about utrace.

Robert N M Watson
Computer Laboratory
University of Cambridge


>
>> I also have patches I use at work that allow kdump to recognize a 32-bit
>> malloc utrace on an amd64 machine (for when you run an i386 binary) if folks
>> are interested.  I'm not sure how many i386 on amd64 hacks we want in the
>> official CVS tree. :)
>
> Personally, I'd like FreeBSD to behave similarly to Solaris:  You choose
> whether to compile 32-bit or 64-bit executables with a compiler switch
> and everything else is transparent.  FreeBSD 3.x had smarts so that nm,
> ld, gdb etc could transparently handle either a.out or ELF executables.
> It would be nice if FreeBSD/amd64 could do the same (though I realise
> that we don't want the overheads on other platforms, which would make it
> more difficult to implement).
>
>> I also have another set of patches to add various utrace(2) events to the
>> runtime linker as well as logic in kdump to parse them that I hope to commit
>> in the near future.
>
> Sounds good.  This goes back to my first point above - I don't think it's
> safe to rely on the size of a utrace record to determine its type.
>
> -- 
> Peter Jeremy
>