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

[Peter Jeremy]

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).

>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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20070106/c7edc97f/attachment.pgp