From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6866 invoked by alias); 9 Dec 2011 21:54:03 -0000 Received: (qmail 6858 invoked by uid 22791); 9 Dec 2011 21:54:02 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 09 Dec 2011 21:53:50 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pB9LrRsQ021879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Dec 2011 16:53:27 -0500 Received: from host2.jankratochvil.net (ovpn-116-39.ams2.redhat.com [10.36.116.39]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id pB9LrKxE029375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 9 Dec 2011 16:53:24 -0500 Date: Fri, 09 Dec 2011 21:55:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: Joel Brobecker , gdb-patches@sourceware.org Subject: Re: Regression for gdb.base/sigstep.exp with .debug_types Message-ID: <20111209215319.GA5132@host2.jankratochvil.net> References: <20111205081911.GG28486@adacore.com> <20111209171630.GA30059@host2.jankratochvil.net> <20111209171937.GA30594@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-12/txt/msg00316.txt.bz2 On Fri, 09 Dec 2011 21:19:37 +0100, Tom Tromey wrote: > In this case, g++ puts the class "A" into a .debug_types TU. > There is no link from the .debug_info CU to this TU I agree that TU (.debug_types content) is unused there. IMO that TU can be completely ignored. > One is in the CU, but it is ignored when reading debuginfo because class > A is dropped. I do not think it is problem. It is read in, but it has bogus nesting: <1><51>: Abbrev Number: 13 (DW_TAG_class_type) <52> DW_AT_name : A <54> DW_AT_declaration : 1 <2><58>: Abbrev Number: 6 (DW_TAG_subprogram) <59> DW_AT_name : (indirect string, offset: 0x0): func <5f> DW_AT_type : <0x65> <64> DW_AT_declaration : 1 <1><83>: Abbrev Number: 14 (DW_TAG_subprogram) <84> DW_AT_specification: <0x58> <88> DW_AT_low_pc : 0xb <90> DW_AT_high_pc : 0x16 <98> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) [filtered a bit] (gdb) p 'A::func()' $2 = {int (void)} 0x4004df Going to file it to GCC debug/ . I believe with proper GCC debug/ it would work. Not sure now why it worked before but it probably does not matter. > Perhaps g++ is wrong not to emit some CU->TU linkage. If this existed > then maybe we could make a symbol in the CU pointing to the type, > presumably making this test work. GCC did not use that TU here so we also should not I think. > Perhaps the DW_AT_declaration treatment in process_structure_scope is a > bug -- but I would be cautious about changing this before a release. I do not think it is a bug. GDB in general does not care about declarations, only about definitions. Thanks, Jan