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

[John Baldwin]

On Friday 05 January 2007 23:35, 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).

We could turn it off if we want.  I agree that having to depend on size to 
determine the malloc case sucks as a signature, but that format has been 
fairly well established at this point.

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

We have several things at work that we don't currently feed back because it 
makes things ugly.  For example, at work we let 32-bit tcpdump work on amd64 
via compat ioctl's, etc.  (That one is ugly as the kernel actually has to 
send a different header on each packet due to struct timeval being different 
sizes.)

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

For RTLD I am using a 4 byte signature 'RTLD' followed by a byte specifying 
the type of record that follows and do not depend on the size.  I think it 
would be best if any new utrace's used a similar 4-char signature (you could 
even dynamically add handlers based on the signature to kdump that way), but 
for malloc() I was stuck with what we had.  See 
www.freebsd.org/~jhb/patches/rtld_utrace.patch for the approach I used.

-- 
John Baldwin