Re: RFC: partial symbol table address range generalization

[Daniel Jacobowitz <drow at mvista dot com>]

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