cvs commit: src/usr.bin/kdump kdump.c
jhb at freebsd.org
Mon Jan 8 11:20:27 PST 2007
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
> >> human-readable format. Note that we report 'realloc(p, 0)'
> >> 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
> >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
> >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
> >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.
More information about the cvs-src