From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: partial symbol table address range generalization Date: Tue, 23 Oct 2001 21:42:00 -0000 Message-id: <20011024004201.A22007@nevyn.them.org> References: <20011023233450.09F855E9D8@zwingli.cygnus.com> <20011023195430.A15242@nevyn.them.org> X-SW-Source: 2001-10/msg00311.html On Tue, Oct 23, 2001 at 11:15:38PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > I'd like to point you at my thoughts from the first time I noticed this > > behavior: > > < http://sources.redhat.com/ml/gdb/2001-08/msg00161.html > > > That's messed up. The compiler produces SO stabs that describe only > the .text section, while happily placing code in other sections. So > the SO stabs' addresses are useless. > > If you want to hack on the stabs reader to handle these cases, that > would be great. I'm not sure how to, at present. But it may be possible when you're done. Of course, I'd rather transition all the targets I care about to DWARF2 instead of fixing stabs; but if I have time, I'll take a whack at it. > > > There is some logic in GDB's lookup functions to cope with overlapping > > > partial symtabs, and they've been working pretty well on our behalf. > > > However, they're fragile, and do break in everyday use. For example, > > > in the executable produced from the source file above, if you try to > > > set a breakpoint on a library routine compiled without debug > > > information, GDB will set the breakpoint in `main' instead. (On some > > > platforms, `_exit' is such a function.) > > > > This particular problem should be avoidable anyway. I would appreciate > > it if you would look at: > > < http://sources.redhat.com/ml/gdb/2001-09/msg00068.html > > > Well, okay. But I'd much prefer to see the problem fixed by making > the symbol table contents more accurate than by adding another > heuristic for recognizing insane data. When checks like that get into > the code, they never go away, because nobody's ever really sure > whether the circumstances it was meant to cope with happen any more. Well, I wouldn't call it a heuristic in this case. If we don't have debugging info, isn't it a little bit insane to try to find a line number? > If I can finish up the addrset patch for Dwarf 2, would you be > interested in taking a shot at spiffing up stabs? As said, it isn't a priority for me, but it is something that I would like to see cleaned up. Especially when Elena is finished cleaning up the partial-stab.h mess (or has it been finished now? I don't recall). > I encourage you to take a shot at it. The idea is to have `struct > addrset' support a bunch of groovy operations (like set subtraction, > testing for intersections between two sets, etc.), carefully coded and > gotten right once and for all, that make it easy to do this kind of > sanity checking and refinement. Here's the header file for the code > I've got now; imagine adding the setwise ops you want here, and then > using them in the stabs reader. Looks good! The only comment I have is trivial: > /* Set *START and *END to the first and last addresses (inclusive) of > the first contiguous range of addresses in ADDRSET. If ADDRSET is > empty, set *START to 1 and *END to zero. */ > void addrset_first_range (struct addrset *addrset, > CORE_ADDR *start, > CORE_ADDR *end); > > /* Set *START and *END to the first and last addresses (inclusive) of > the first contiguous range of addresses in ADDRSET after AFTER. > (That is, AFTER will not be included in the returned range.) > If there are no addresses in ADDRSET that are > AFTER, then > set *START to 1 and *END to zero. */ > void addrset_next_range (struct addrset *addrset, > CORE_ADDR after, > CORE_ADDR *start, > CORE_ADDR *end); For performance reasons, it might be better to steal the iterator concept and have an opaque cookie separate from the start/end addresses. Otherwise, addrset_next_range is not going to be constant time, and that could get annoying in an objfile with a large number of sections... and C++ is notorious for absurd numbers of sections. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer