From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8980 invoked by alias); 18 Apr 2013 11:47:29 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 8970 invoked by uid 89); 18 Apr 2013 11:47:29 -0000 X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from mail1.bemta8.messagelabs.com (HELO mail1.bemta8.messagelabs.com) (216.82.243.204) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 18 Apr 2013 11:47:28 +0000 Received: from [216.82.242.179:14145] by server-12.bemta-8.messagelabs.com id 89/44-29795-E4DDF615; Thu, 18 Apr 2013 11:47:26 +0000 X-Env-Sender: JENS.ELMENTHALER@advantest.com X-Msg-Ref: server-11.tower-86.messagelabs.com!1366285645!34225860!1 X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31111 invoked from network); 18 Apr 2013 11:47:25 -0000 Received: from mx2.advantest.co.jp (HELO mx2.advantest.co.jp) (61.121.102.101) by server-11.tower-86.messagelabs.com with SMTP; 18 Apr 2013 11:47:25 -0000 Received: from smtp-3.jp.advantest.com (smtp-3.jp.advantest.com [150.85.253.72]) by mx2.advantest.co.jp (Postfix) with ESMTP id 071B25A52D6 for ; Thu, 18 Apr 2013 20:47:25 +0900 (JST) Received: from smtp-3.jp.advantest.com ([127.0.0.1]) by smtp-3.jp.advantest.com (Sun Java System Messaging Server 6.2-9.16 (built Feb 27 2009)) with ESMTP id <0MLG00IBN8R05XE0@smtp-3.jp.advantest.com> for gdb@sourceware.org; Thu, 18 Apr 2013 20:47:24 +0900 (JST) Received: from USPLSVPEX002.ent.rt.verigy.net (usplsvpex002.ent.rt.verigy.net [10.16.58.176]) by smtp-3.jp.advantest.com (Postfix) with ESMTP id 53F1041A2 for ; Thu, 18 Apr 2013 20:47:24 +0900 (JST) Received: from DEBOSVPEX002.ent.rt.verigy.net (10.17.10.105) by USPLSVPEX002.ent.rt.verigy.net (10.16.58.176) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 18 Apr 2013 06:47:23 -0500 Received: from DEBOSVPEX001.ent.rt.verigy.net ([169.254.3.16]) by DEBOSVPEX002.ent.rt.verigy.net ([10.17.10.105]) with mapi id 14.02.0328.009; Thu, 18 Apr 2013 13:47:19 +0200 Date: Thu, 18 Apr 2013 11:47:00 -0000 From: "Elmenthaler, Jens" Subject: RE: gdb bug or corrupt dwarf info? In-reply-to: <87ip4bb6d1.fsf@fleche.redhat.com> To: "gdb@sourceware.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable References: <87ip4bb6d1.fsf@fleche.redhat.com> X-SW-Source: 2013-04/txt/msg00054.txt.bz2 Tom, thanks for your quick answer. This type of debug info indeed seems to= depend on the gcc version. I tried a gcc 4.7.2 and the debug info looks al= l nice and clean. Unfortunately, my target environment is a RedHat 5.8 with a gcc 4.1.2. and = upgrading the gcc is not an option. All I can touch is the gdb. So I developed a patch, applying the following reasoning: - The bug is that a child lexical scope is erroneously output as the succes= sor sibling of the parent - if lexical block scope A is a real sibling of lexical block scope B, the = address range of A will not be a subrange of B, nor vice versa. - So I can detect a bogus child by looking at the successor sibling. If the= successor sibling's address range is a subrange of the predecessor sibling= , I treat it as a child. I added the following code to read_lexical_block_scope(), right behind the = processing of the children. In case the test is positive, I "repair" the af= fected die_info's: struct die_info *sibling =3D sibling_die(die); if (sibling && (sibling->tag =3D=3D DW_TAG_lexical_block)) { CORE_ADDR sibling_lowpc, sibling_highpc; if (dwarf2_get_pc_bounds(sibling, &sibling_lowpc, &sibling_highpc, cu= , NULL )) { sibling_lowpc +=3D baseaddr; sibling_highpc +=3D baseaddr; if (lowpc <=3D sibling_lowpc && sibling_highpc <=3D highpc) { die->sibling =3D sibling->sibling; sibling->sibling =3D NULL; sibling->parent =3D die; if (die->child) { struct die_info *child; for (child =3D die->child; sibling_die(child); child =3D = sibling_die(child)) { } child->sibling =3D sibling; } else { die->child =3D sibling; } process_die(sibling, cu); } } } First tests seem promising, so is there any reason I shouldn't do this? Jens. -----Original Message----- From: Tom Tromey [mailto:tromey@redhat.com]=20 Sent: Thursday, March 28, 2013 9:46 PM To: Elmenthaler, Jens Cc: gdb@sourceware.org Subject: Re: gdb bug or corrupt dwarf info? >>>>> "Jens" =3D=3D Elmenthaler, Jens writ= es: Jens> I'm currently investigation why gdb is only showing 'i' as local=20 Jens> variable in the following loop body, and not also 'text': Jens> So my question now is, whether this is a gdb bug which I possibly=20 Jens> could fix, or whether the debug info is broken. Jens> In my opinion it looks suspicious that the lexical block=20 Jens> containing 'text' is not a child of the lexical block containing=20 Jens> 'i', but a sibling. I am not sure if it is invalid DWARF. There isn't much in DWARF that prohi= bits odd output like this. Maybe such a prohibition is in there -- I could= n't quickly find it, but that isn't definitive. This DWARF is definitely not what gdb expects. gdb expects lexical blocks = to be nested and not to overlap. However, see the "???" comment in read_le= xical_block_scope -- there appears to be some room for improvement, though = it is unclear to me if trying to handle the DWARF you have is worth the eff= ort. In particular the comment refers to how to handle disjoint ranges, bu= t your problem is both disjoint ranges in one scope combined with an overla= p of another scope. I would say that it is both a compiler bug and a gdb bug. The blocks ought to nest, and there doesn't seem to me to be a good reason = to use the representation you are seeing. Tom