From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16272 invoked by alias); 4 Feb 2003 14:59:44 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 16265 invoked from network); 4 Feb 2003 14:59:43 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 4 Feb 2003 14:59:43 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h14Exhf22074 for ; Tue, 4 Feb 2003 09:59:43 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h14Exha32460; Tue, 4 Feb 2003 09:59:43 -0500 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h14ExfX09208; Tue, 4 Feb 2003 09:59:41 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id 2F552FF79; Tue, 4 Feb 2003 10:03:54 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15935.54873.954978.898947@localhost.redhat.com> Date: Tue, 04 Feb 2003 14:59:00 -0000 To: Daniel Jacobowitz Cc: Elena Zannoni , Jim Blandy , Richard Henderson , gdb-patches@sources.redhat.com Subject: Re: [RFC] Partial support for dwarf3 DW_AT_ranges In-Reply-To: <20030129224502.GA25158@nevyn.them.org> 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> X-SW-Source: 2003-02/txt/msg00114.txt.bz2 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