This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] Partial support for dwarf3 DW_AT_ranges
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: Elena Zannoni <ezannoni at redhat dot com>, Jim Blandy <jimb at redhat dot com>, Richard Henderson <rth at redhat dot com>, gdb-patches at sources dot redhat dot com
- Date: Tue, 4 Feb 2003 10:03:53 -0500
- Subject: Re: [RFC] Partial support for dwarf3 DW_AT_ranges
- References: <20011231003448.A3399@redhat.com><15413.57239.249007.204757@localhost.localdomain><20030129155346.GA13172@nevyn.them.org><15928.6608.942581.500183@localhost.redhat.com><20030129212757.GA5515@nevyn.them.org><20030129224502.GA25158@nevyn.them.org>
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