Date: Tue, 20 Jul 2004 04:39:40 -0600 (MDT) From: Scott Long <scottl@freebsd.org> To: Mark Kettenis <kettenis@gnu.org> Cc: marcel@xcllnt.net Subject: Re: cvs commit: src/sys/kern imgact_elf.c Message-ID: <20040720043824.X32601@pooker.samsco.org> In-Reply-To: <200407200958.i6K9wZD4022358@juw15.nfra.nl> References: <200407182028.i6IKS7Su002490@repoman.freebsd.org> <20040719171041.GA22048@ns1.xcllnt.net> <200407200958.i6K9wZD4022358@juw15.nfra.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Jul 2004, Mark Kettenis wrote: > Date: Mon, 19 Jul 2004 10:10:41 -0700 > From: Marcel Moolenaar <marcel@xcllnt.net> > > On Mon, Jul 19, 2004 at 03:45:39AM -0600, Scott Long wrote: > > I've seen concern (maybe in private email, can't check at the moment) > > recently that loosing the PID info is undesirable. Is there any way that > > it can be included again, maybe in something other than a PRSTATUS object? > > Ideally you want one note that describes the process as a whole (let's > call it a P-note for now) and as many notes as there were kernel threads > for the process (let's call such notes T-notes). > > Defenitely. > > A P-note would typically hold the PID. T-notes typically hold register > contents, as well as LWPIDs. > > Essentially, yes. > > Creating a core file with P-notes and T-notes is easy enough. getting > binutils to grok them is non-trivial, not to mention that gdb needs > to be able to get to the information, which is as non-trivial as > binutils extracting it from the core file. So, introducing new notes > is a major effort. Extending existing notes is a major effort. Not > because it's hard to understand a new note, or read a new field from > a note, but because it's hard to have binutils save the information > and gdb use the saved information. You pretty much have to redesign > interfaces and I'm not touching that... > > I think a redesign of the core file format along the lines you said > above would defenitely pay off. The NetBSD folks have done it, and I > think their approach is pretty elegant. An improtant benefit of their > approach is that it's (almost) machine independent. The BFD code is > pretty much localized in elf.c (look for the functions with netbsd in > their names). Adapting that code for FreeNSD should not be much work. > I don't think any further changes to GDB are needed. > > For a description of the format you can look at the NetBSD core(5) man > page. The T-notes are simply dumps of `struct reg' and `struct > fpreg'. The LWPIDs are encoded in the name of those notes. > > Please realize that the problems you're citing largely stem from the > let's simulate-Linux-which-simulates-SVR4 type notes currently used by > FreeBSD. Throwing that all overboard will save much trouble in the > future. > > I'm certainly willing to do some of the legwork, since it'd make life > for me on the GDB side a lot easier if you'd adapt these NetBSD-style > core file notes. I certainly have some time the coming weeks to spend > on it. > > Mark > I think it's a little late in the 5.3/5-STABLE game to change the corefile format. I do, however, like this idea a lot. Getting it done early on in the 6.x cycles would be a really good thing. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040720043824.X32601>