Re: RFC: partial symbol table address range generalization

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, Oct 23, 2001 at 06:34:50PM -0500, Jim Blandy wrote:
> At the moment, GDB's partial symbol table structures assume that each
> compilation unit's text occupies a single contiguous range of
> addresses.  If a given address falls between a `struct partial_symtab'
> structure's `texthigh' and `textlow' addresses, then GDB assumes that
> reading that partial symbol table's debugging info will provide
> complete information about that address.
> 
> However, this assumption isn't true.  A given .o file's code can
> actually appear in any number of distinct regions, separated by code
> from other .o files.  This can happen when we compile and link a C++
> program, like the below (from GCC's test suite):

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 >

When I looked at this problem in August, I wasn't brave enough to
suggest the solution you're proposing (which I completely agree with). 
However...

> 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 >

As far as getting this information from the stabs reader, we should be
able to do it if we know separate "possible" and "definite" ranges, I
think.  I'm not sure if we have enough information to do this.  We
don't for the general case, but we should generally have one "definite"
range per file (corresponding to the main .text segment).  It would be
nice to at least take this region out of any symtabs that seem to
encompass it, so that if the main program is built without
-ffunction-sections, we will behave sanely in the presence of (say)
libstdc++.a.


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer