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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
