Re: [RFC] Partial support for dwarf3 DW_AT_ranges

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, Feb 04, 2003 at 10:03:53AM -0500, Elena Zannoni wrote:
> 
> Daniel, did you file a gcc bug report for this?

Nope.  I don't know what compiler Jakub was using to build the test he
gave us, other than the fact that it emits DW_AT_ranges.  So I don't
have enough information to know whether there's still a problem.

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer