Date: Sat, 6 Jan 2007 15:35:15 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: John Baldwin <jhb@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/usr.bin/kdump kdump.c Message-ID: <20070106043515.GD839@turion.vk2pj.dyndns.org> In-Reply-To: <200701051607.59334.jhb@freebsd.org> References: <200701052104.l05L4cO7037092@repoman.freebsd.org> <200701051607.59334.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--NtwzykIc2mflq5ck Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 >>=20 >> FreeBSD src repository >>=20 >> Modified files: >> usr.bin/kdump kdump.c=20 >> Log: >> Add code to parse the utrace(2) entries generated by malloc(3) in a mo= re >> 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. >> =20 >> 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= =20 >malloc utrace on an amd64 machine (for when you run an i386 binary) if fol= ks=20 >are interested. I'm not sure how many i386 on amd64 hacks we want in the= =20 >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= =20 >runtime linker as well as logic in kdump to parse them that I hope to comm= it=20 >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. --=20 Peter Jeremy --NtwzykIc2mflq5ck Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFnycD/opHv/APuIcRAjC0AJsEYV7Mc4FF2/leKGELptBA/TesbACfbDRD PWpsDxC2eCsViJOOI48V9t4= =Jvhv -----END PGP SIGNATURE----- --NtwzykIc2mflq5ck--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070106043515.GD839>