This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFC: partial symbol table address range generalization
On Tue, Oct 23, 2001 at 11:15:38PM -0500, Jim Blandy wrote:
>
> Daniel Jacobowitz <drow@mvista.com> 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