From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23490 invoked by alias); 25 Mar 2010 16:27:13 -0000 Received: (qmail 23461 invoked by uid 22791); 25 Mar 2010 16:27:10 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.17.165) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 25 Mar 2010 16:27:05 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.1/8.13.1) with ESMTP id o2PGR2we007708 for ; Thu, 25 Mar 2010 16:27:02 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o2PGR2EU1626246 for ; Thu, 25 Mar 2010 17:27:02 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o2PGR10N002856 for ; Thu, 25 Mar 2010 17:27:01 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id o2PGR0Mm002491 for ; Thu, 25 Mar 2010 17:27:00 +0100 Message-Id: <201003251627.o2PGR0Mm002491@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 25 Mar 2010 17:27:00 +0100 Subject: [rfc] Fix some cases of "using" declarations with older G++ versions To: gdb-patches@sourceware.org Date: Thu, 25 Mar 2010 16:27:00 -0000 From: "Ulrich Weigand" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: 2010-03/txt/msg00846.txt.bz2 Hello, I'm seeing the following test case failure: FAIL: gdb.cp/nsusing.exp: print ghx Looking at a reduced version of the test case: namespace G { namespace H { int ghx = 6; } } namespace I { int marker () { using namespace G::H; return ghx; } } int main () { return I::marker (); } I get the following DWARF info with GCC 4.1: <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : 0 DW_AT_high_pc : 0x1000052c DW_AT_low_pc : 0x100004cc DW_AT_producer : GNU C++ 4.1.2 20080704 (Red Hat 4.1.2-46) DW_AT_language : 4 (C++) DW_AT_name : nsusing.cc DW_AT_comp_dir : /home/uweigand/fsf/gdb-head-build/gdb <1><74>: Abbrev Number: 2 (DW_TAG_namespace) DW_AT_sibling : DW_AT_name : I DW_AT_decl_file : 1 DW_AT_decl_line : 10 <2><7d>: Abbrev Number: 3 (DW_TAG_subprogram) DW_AT_sibling : DW_AT_external : 1 DW_AT_name : marker DW_AT_decl_file : 1 DW_AT_decl_line : 11 DW_AT_MIPS_linkage_name: _ZN1I6markerEv DW_AT_type : DW_AT_declaration : 1 <3>: Abbrev Number: 4 (DW_TAG_imported_module) DW_AT_decl_file : 1 DW_AT_decl_line : 13 DW_AT_import : <2>: Abbrev Number: 5 (DW_TAG_subprogram) DW_AT_specification: <7d> DW_AT_declaration : 1 <1>: Abbrev Number: 6 (DW_TAG_base_type) DW_AT_name : int DW_AT_byte_size : 4 DW_AT_encoding : 5 (signed) <1>: Abbrev Number: 2 (DW_TAG_namespace) DW_AT_sibling : DW_AT_name : G DW_AT_decl_file : 1 DW_AT_decl_line : 2 <2>: Abbrev Number: 7 (DW_TAG_namespace) DW_AT_name : H DW_AT_decl_file : 1 DW_AT_decl_line : 4 <3>: Abbrev Number: 8 (DW_TAG_variable) DW_AT_name : ghx DW_AT_decl_file : 1 DW_AT_decl_line : 5 DW_AT_MIPS_linkage_name: _ZN1G1H3ghxE DW_AT_type : DW_AT_external : 1 DW_AT_declaration : 1 <1>: Abbrev Number: 9 (DW_TAG_subprogram) DW_AT_specification: DW_AT_low_pc : 0x100004cc DW_AT_high_pc : 0x100004f4 DW_AT_frame_base : 0 (location list) <1>: Abbrev Number: 10 (DW_TAG_subprogram) DW_AT_external : 1 DW_AT_name : main DW_AT_decl_file : 1 DW_AT_decl_line : 18 DW_AT_type : DW_AT_low_pc : 0x100004f4 DW_AT_high_pc : 0x1000052c DW_AT_frame_base : 0x2b (location list) <1><10a>: Abbrev Number: 11 (DW_TAG_variable) DW_AT_specification: DW_AT_location : 5 byte block: 3 10 1 a 8c (DW_OP_addr: 10010a8c) Note that there is a DW_TAG_imported_module DIE corresponding to the using declaration in function I::marker, but this is a child of the declaration DIE <7d>. The associated function *definition* DIE does not register the using statement at all; however, it refers via DW_AT_specification links (indirectly via ) to <7d>. The problem seems to be that while in many cases, DW_AT_specification links are followed, this is not the case when using declarations are being considered. I'm not fully sure if this is supposed to be working according to the DWARF spec, but it looks like it should. The following patch extends read_func_scope to following specification links and parse them for DW_TAG_imported_module DIEs. This fixes the test case for me. (Note that with current GCC, the imported module DIE seems to always be a child of a DW_TAG_lexical_block, and never of a DW_TAG_subprogram. The lexical block DIEs do not support specification links, so the problem goes away here.) Tested on powerpc64-linux with no regressions, fixes the above FAIL. Does this look reasonable? Bye, Ulrich ChangeLog: * dwarf2read.c (read_func_scope): Also scan specification DIEs for DW_TAG_imported_module children. Index: gdb/dwarf2read.c =================================================================== RCS file: /cvs/src/src/gdb/dwarf2read.c,v retrieving revision 1.372 diff -u -p -r1.372 dwarf2read.c --- gdb/dwarf2read.c 22 Mar 2010 13:21:39 -0000 1.372 +++ gdb/dwarf2read.c 25 Mar 2010 15:14:13 -0000 @@ -3940,6 +3940,30 @@ read_func_scope (struct die_info *die, s inherit_abstract_dies (die, cu); + /* If we have a DW_AT_specification, we might need to import using + directives from the context of the specification DIE. See the + comment in determine_prefix. */ + if (cu->language == language_cplus) + { + struct dwarf2_cu *spec_cu = cu; + struct die_info *spec_die = die_specification (die, &spec_cu); + + while (spec_die) + { + child_die = spec_die->child; + while (child_die && child_die->tag) + { + if (child_die->tag == DW_TAG_imported_module) + process_die (child_die, cu); + child_die = sibling_die (child_die); + } + + /* In some cases, GCC generates specification DIEs that + themselves contain DW_AT_specification attributes. */ + spec_die = die_specification (spec_die, &spec_cu); + } + } + new = pop_context (); /* Make a block for the local symbols within. */ block = finish_block (new->name, &local_symbols, new->old_blocks, -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com