Re: [RFC] Partial support for dwarf3 DW_AT_ranges

[Daniel Jacobowitz <drow@mvista.com>]

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