Re: [RFC] Partial support for dwarf3 DW_AT_ranges

[Elena Zannoni <ezannoni@redhat.com>]

Daniel, did you file a gcc bug report for this?

elena


Daniel Jacobowitz writes:
 > On Wed, Jan 29, 2003 at 04:27:57PM -0500, Daniel Jacobowitz wrote:
 > > On Wed, Jan 29, 2003 at 01:13:36PM -0500, Elena Zannoni wrote:
 > > > Daniel Jacobowitz writes:
 > > >  > On Fri, Jan 04, 2002 at 12:00:07PM -0500, Elena Zannoni wrote:
 > > >  > > Richard Henderson writes:
 > > >  > >  > GCC began emitting DW_AT_ranges back in September to deal with
 > > >  > >  > lexical scopes made discontiguous by basic block reordering.
 > > >  > >  > 
 > > >  > >  > As of today, it may also create discontiguous lexical scopes
 > > >  > >  > due to scheduling.  (Before today under the same circumstances
 > > >  > >  > we'd lose track of which instructions belonged to which scope
 > > >  > >  > and fail to emit any debug information whatsoever.)
 > > >  > >  > 
 > > >  > > 
 > > >  > > Richard, there was some initial effort to deal with this problem
 > > >  > > in gdb's symbol tables structures back in October.
 > > >  > > See the thread at:
 > > >  > > http://sources.redhat.com/ml/gdb-patches/2001-10/msg00304.html
 > > >  > > However, no real changes have been made to the symbol tables yet.
 > > >  > > 
 > > >  > >  > However, GDB doesn't recognize DW_AT_ranges as a valid way of
 > > >  > >  > marking a lexical scope, which causes it to discard the scope
 > > >  > >  > entirely.  Which is probably the least useful thing that could
 > > >  > >  > be done.
 > > >  > >  > 
 > > >  > >  > The following does not add proper support for discontiguous
 > > >  > >  > address ranges.  I couldn't figure out how to do that in any
 > > >  > >  > way that wasn't horribly invasive.  I'm willing to expend a
 > > >  > >  > significant amount of effort on this if someone is willing to
 > > >  > >  > provide some direction.
 > > >  > >  > 
 > > >  > > 
 > > >  > > The thread mentioned above has some initial implementation of an
 > > >  > > address set for partial symbol tables which would be used in case of
 > > >  > > non contiguous addr ranges. You should coordinate with Jim.
 > > >  > > 
 > > >  > >  > What this does do is find the "bounding box" of the discontiguous
 > > >  > >  > range and use that.  Yes, that will do the wrong thing in some
 > > >  > >  > circumstances, but the current behaviour is wrong under all
 > > >  > >  > circumstances, so it may be a net improvement.
 > > >  > >  > 
 > > >  > > 
 > > >  > > I am OK with committing some initial support. At least now gdb can
 > > >  > > read the info. 
 > > >  > > 
 > > >  > > I have a few comments on your changes.  Maybe I am missing it, but is
 > > >  > > the -1 value returned by dwarf2_get_pc_bounds used anywhere yet? If
 > > >  > > not, I would suggest we don't bother with it right now, given that the
 > > >  > > final solution will probably have to restructure that function again.
 > > >  > > Also, I would not want to introduce more goto's in gdb. I think that
 > > >  > > that sequence can be rewritten w/o goto's pretty easily.  Also there
 > > >  > > is some formatting problem (white spaces around operators, full names
 > > >  > > for variables).  Adding some comments on how the .debug_ranges list is
 > > >  > > organized would be helpful too.
 > > >  > > 
 > > >  > > I think JimB is the one which has the last say on this however, since
 > > >  > > he has a patch in the works.
 > > >  > > 
 > > >  > 
 > > >  > Ping out there, folks.
 > > >  > 
 > > >  > This lack of support for DW_AT_ranges is responsible for at least one,
 > > >  > probably two or more of the current PRs about "missing local
 > > >  > variables".  Affected GCC versions have been shipping for some time; at
 > > >  > least 3.2 generates DW_AT_ranges, maybe earlier.
 > > > 
 > > > Yes, I am looking at this patch at the moment, too. The lack of this
 > > > feature is creating lots of troubles. 
 > > > 
 > > >  > 
 > > >  > Since nothing ever came of the grand plans to support ranges in the
 > > >  > symbol table directly, can we at least move forwards on this year-old
 > > >  > patch?  If so, I'll update it for current GDB.
 > > >  > 
 > > > 
 > > > If you have time, I'd appreciate it. I have adapted the patch to the
 > > > current sources, but even with it, I wasn't able to make Jakub's
 > > > example work.  The example is in PR 833.
 > > > I can send you the diffs I have, if it helps.
 > > 
 > > I'm going to go look at the GCC code that generates these, and the
 > > current standard...  It looks like the meaning has changed since GCC
 > > started using them.  Or else GCC broke at some point.
 > 
 > My conclusions from today are:
 >   - Richard's patch works.  The ugliest bit of it (the linear search
 > for a base address) is not necessary according to the DWARF-3 standard
 > (draft 8).  I'll redo the patch without that and post it this evening.
 > I think that with that revision, the patch should be included.
 > 
 >   - Jakub's testcase reveals some other problems.  Two, in particular:
 > 
 >     - GDB actually needs to be aware of the address ranges to get it
 >       right; there are interleaved blocks and we're getting the wrong
 >       one.  We already knew this would happen.  That's one reason the
 >       test fails.
 > 
 >     - GCC's debug info is wrong.  It outputs a lexical block for the
 >       large for loop, a nested lexical block for one inner block, and
 >       a sibling lexical block for another inner block - that is, the
 >       block is actually inside the for loop, and the debug info claims
 >       it is lexically outside the loop.  Presumably an optimizer
 >       somewhere is eating it.  This happens to be the block GDB decides
 >       we're in, which is why we lose.  That's the other reason.
 > 
 > 
 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer