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: Daniel Jacobowitz <drow at mvista dot com>
- To: Elena Zannoni <ezannoni at redhat dot com>
- Cc: 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:05:06 -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> <15935.54873.954978.898947@localhost.redhat.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