This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[rfc] Fix some cases of "using" declarations with older G++ versions


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><b>: 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     : <af>
     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     : <a8>
     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        : <af>
     DW_AT_declaration : 1
 <3><a0>: Abbrev Number: 4 (DW_TAG_imported_module)
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 13
     DW_AT_import      : <bf>
 <2><a8>: Abbrev Number: 5 (DW_TAG_subprogram)
     DW_AT_specification: <7d>
     DW_AT_declaration : 1
 <1><af>: Abbrev Number: 6 (DW_TAG_base_type)
     DW_AT_name        : int
     DW_AT_byte_size   : 4
     DW_AT_encoding    : 5      (signed)
 <1><b6>: Abbrev Number: 2 (DW_TAG_namespace)
     DW_AT_sibling     : <e0>
     DW_AT_name        : G
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 2
 <2><bf>: Abbrev Number: 7 (DW_TAG_namespace)
     DW_AT_name        : H
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 4
 <3><c4>: 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        : <af>
     DW_AT_external    : 1
     DW_AT_declaration : 1
 <1><e0>: Abbrev Number: 9 (DW_TAG_subprogram)
     DW_AT_specification: <a8>
     DW_AT_low_pc      : 0x100004cc
     DW_AT_high_pc     : 0x100004f4
     DW_AT_frame_base  : 0      (location list)
 <1><f1>: 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        : <af>
     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: <c4>
     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 <e0>
does not register the using statement at all; however, it refers
via DW_AT_specification links (indirectly via <a8>) 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]