Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: gdb-patches@sourceware.org
Subject: [rfc] Work around buggy GCC 4.1 namespace dwarf info (GCC PR c++/28460)
Date: Fri, 19 Mar 2010 12:37:00 -0000	[thread overview]
Message-ID: <201003191237.o2JCbBAr020607@d12av02.megacenter.de.ibm.com> (raw)

Hello,

since recent patches to improve C++ namespace support went in, I'm seeing
large numbers (>150) of C++ test case failures.  It turns out that these
were caused by a bug in G++ 4.1 (GCC PR c++/28460) that generates bogus
DW_TAG_namespace DIEs for the global namespace.

With current GDB these bogus DIEs have the effect that the debugger will
no longer have debug info for any global variable.  This seriously affects
debugging capabilities ...

While the bug is indeed in GCC rather than GDB (and has long since been
fixed), I'm wondering whether it would still make sense for us to work
around the problem, because:
- GCC 4.1 is still in widespread use (e.g. as system compiler in RHEL 5.x
  and SLES 10).
- The impact of the bug seriously affects debugging with current
  mainline GDB.

Note that there is precendent for working around buggy GCC debug info
generation in serious cases already ...

The following patch works around the problem for me.
Tested on powerpc-linux, fixes (most) C++ test case failures.

Any comments?  Does anybody see a simpler way to work around the problem?

Bye,
Ulrich

  
ChangeLog:

	* dwarf2read.c (partial_die_parent_scope): Work around buggy
	GCC 4.1 debug info generation (GCC PR c++/28460).
	(determine_prefix): Likewise.


Index: gdb/dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.370
diff -u -p -r1.370 dwarf2read.c
--- gdb/dwarf2read.c	17 Mar 2010 19:16:02 -0000	1.370
+++ gdb/dwarf2read.c	18 Mar 2010 19:26:51 -0000
@@ -2307,6 +2307,19 @@ partial_die_parent_scope (struct partial
 
   grandparent_scope = partial_die_parent_scope (parent, cu);
 
+  /* GCC 4.0 and 4.1 had a bug (PR c++/28460) where they generated bogus
+     DW_TAG_namespace DIEs with a name of "::" for the global namespace.
+     Work around this problem here.  */
+  if (cu->language == language_cplus
+      && parent->tag == DW_TAG_namespace 
+      && strcmp (parent->name, "::") == 0
+      && grandparent_scope == NULL)
+    {
+      parent->scope = NULL;
+      parent->scope_set = 1;
+      return NULL;
+    }
+
   if (parent->tag == DW_TAG_namespace
       || parent->tag == DW_TAG_structure_type
       || parent->tag == DW_TAG_class_type
@@ -9012,6 +9025,12 @@ determine_prefix (struct die_info *die, 
       {
       case DW_TAG_namespace:
 	parent_type = read_type_die (parent, cu);
+	/* GCC 4.0 and 4.1 had a bug (PR c++/28460) where they generated bogus
+	   DW_TAG_namespace DIEs with a name of "::" for the global namespace.
+	   Work around this problem here.  */
+	if (cu->language == language_cplus
+	    && strcmp (TYPE_TAG_NAME (parent_type), "::") == 0)
+	  return "";
 	/* We give a name to even anonymous namespaces.  */
 	return TYPE_TAG_NAME (parent_type);
       case DW_TAG_class_type:
-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


             reply	other threads:[~2010-03-19 12:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-19 12:37 Ulrich Weigand [this message]
2010-03-19 12:59 ` Daniel Jacobowitz
2010-03-19 19:20 ` [patch-testcase] " Jan Kratochvil
2010-03-19 20:21   ` Daniel Jacobowitz
2010-03-20  1:30   ` Tom Tromey
2010-03-21 19:42     ` Jan Kratochvil
2010-03-22 13:23   ` Ulrich Weigand
2010-03-22 16:55     ` Jan Kratochvil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201003191237.o2JCbBAr020607@d12av02.megacenter.de.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox