[Bug debug/19769] [4.0 Regression] GCC produces wrong dwarf2 output that breaks gdb

[Bug debug/19769] [4.0 Regression] GCC produces wrong dwarf2 output that breaks gdb

[aph at gcc dot gnu dot org]

------- Additional Comments From aph at gcc dot gnu dot org  2005-02-11 12:07 -------
This is a workaround for everyone that needs to use debugging on HEAD.

If we can't get this bug fixed soon something like this will need to be committed.


Index: include/posix-threads.h
===================================================================
RCS file: /cvs/gcc/gcc/libjava/include/posix-threads.h,v
retrieving revision 1.26
diff -u -r1.26 posix-threads.h
--- include/posix-threads.h     11 Oct 2004 17:49:39 -0000      1.26
+++ include/posix-threads.h     11 Feb 2005 12:05:52 -0000
@@ -204,12 +204,10 @@
 _Jv_Thread_t *_Jv_ThreadInitData (java::lang::Thread *thread);
 void _Jv_ThreadDestroyData (_Jv_Thread_t *data);
 
-inline java::lang::Thread *
-_Jv_ThreadCurrent (void)
-{
-  extern pthread_key_t _Jv_ThreadKey;
-  return (java::lang::Thread *) pthread_getspecific (_Jv_ThreadKey);
-}
+
+extern pthread_key_t _Jv_ThreadKey;
+#define _Jv_ThreadCurrent()                                            \
+  ((java::lang::Thread *) pthread_getspecific (_Jv_ThreadKey))
 
 #ifdef JV_HASH_SYNCHRONIZATION
 // Should be specialized to just load the "current thread" register
@@ -339,12 +337,9 @@
 
 #endif /* JV_HASH_SYNCHRONIZATION */
 
-inline _Jv_Thread_t *
-_Jv_ThreadCurrentData (void)
-{
-  extern pthread_key_t _Jv_ThreadDataKey;
-  return (_Jv_Thread_t *) pthread_getspecific (_Jv_ThreadDataKey);
-}
+extern pthread_key_t _Jv_ThreadDataKey;
+#define _Jv_ThreadCurrentData()                                        \
+   ((_Jv_Thread_t *) pthread_getspecific (_Jv_ThreadDataKey))
 
 inline void
 _Jv_ThreadYield (void)


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug debug/19769] [4.0 Regression] GCC produces wrong dwarf2 output that breaks gdb

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-02-14 19:28 -------
> This is a workaround for everyone that needs to use debugging on HEAD.

Works fine on SPARC.  Thanks a lot!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-09 19:52 -------
I almost think this is a C++ front-end bug.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|debug                       |c++


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb

[jbuck at gcc dot gnu dot org]

------- Additional Comments From jbuck at gcc dot gnu dot org  2005-03-09 20:10 -------
Severity raised to "critical" since it breaks debugging of all Java programs
(gdb dies when loading libgcj).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb

[dberlin at dberlin dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2005-03-09 20:28 -------
Subject: Re:  [4.0/4.1 Regression] GCC produces wrong dwarf2
	output that breaks gdb

On Wed, 2005-03-09 at 20:10 +0000, jbuck at gcc dot gnu dot org wrote:
> ------- Additional Comments From jbuck at gcc dot gnu dot org  2005-03-09 20:10 -------
> Severity raised to "critical" since it breaks debugging of all Java programs
> (gdb dies when loading libgcj).
> 

Just FYI, there are two possibilities here:

1. Something is lying to the dwarf2 outputter about the origins of
various things, and which are real instances, and which are not,
2. The dwarf2 outputter is ignoring this and making assumptions about
how things relate to each other based on the order they are output in.


Hopefully this bug is #1, and somewhere in the C++ FE.
The fact that the obvious C version doesn't cause a problem makes me
think this may be the case.
It's also theoretically easier to fix.

If it's #2, it will be a serious pain to fix this, because the real fix
is to make the dwarf2 outputter not depend on the order you hand it
decls in order to get correct debug info.

--Dan




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb

[wilson at gcc dot gnu dot org]

------- Additional Comments From wilson at gcc dot gnu dot org  2005-03-13 03:11 -------
Dan's example doesn't work because 'int' is a predefined type.  Use a unique
structure type put the function call back in the inline function, and I get a
nice little example (22 lines) that can reproduce the problem.  If I compile it with
    ./xgcc -B./ -O -g tmp.cc
and then run gdb on the a.out file, I get a gdb internal error.

Looking at the debug info, I now have 4 DIEs for the variable i.  There are the
same 3 as Dan's example, plus a fourth one, with global scope, that has the
abstract origin pointing back at the declaration inside the inline function.  It
is this fourth one that confuses gdb.

This is using mainline, last updated Thursday March 10, on an x86-64 linux machine.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb

[drow at false dot org]

------- Additional Comments From drow at false dot org  2005-03-13 03:36 -------
Subject: Re:  [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb

Hmm, I can't reproduce the error using mainline for i386-linux, and
several versions of GDB.  Could you attach readelf -wi output for the
file which does cause gdb to crash?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb

[wilson at gcc dot gnu dot org]

------- Additional Comments From wilson at gcc dot gnu dot org  2005-03-16 03:46 -------
I confirmed that I don't see the problem if I compile with -m32 on a x86-64 system.

This happens with 32-bit x86 code because update_equiv_regs deletes and
reinserts the instruction that loads the value of the variable i.  This causes
us to lose the block info for this insn, as block info is based on insn uid. 
This does not happen for 64-bit code because CLASS_LIKELY_SPILLED_P is true for
the register destination.  For 32-bit code, the register has a preferred class
of GENERAL_REGS, and for 64-bit code, the register has a preferred class of
DIREG_CLASS.  So the 32-bit x86 case doesn't fail because we lost some debug info.

I can make the 32-bit case fail by adding the -fpic option, which prevents
update_equiv_regs from optimizing this instructions.

So
  ./xgcc -B./ -O -g -fpic -m32 tmp.cc
reproduces the problem for me on an x86_64 machine.  It should do likewise on a
32-bit machine, without the -m32 option.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb

[wilson at gcc dot gnu dot org]

------- Additional Comments From wilson at gcc dot gnu dot org  2005-03-16 03:54 -------
Part of the problem here is the way that declare_in_namespace works. 
gen_variable_die, calls declare_in_namespace, which checks to see if the
variable has a namespace, and if so emits it into that namespace. 
declare_in_namespace then returns, and gen_variable_die finishes normally, which
means we end up with DIEs for one variable.  The local one in the current
context, and the one emitted into the namespace.  The variable in question here
has a namespace of "::".

When we process the abstract instance of f, we emit a local die for i into f,
and a namespace one into :: the global context.  This one has line 3.  Then we
see the global redeclaration, and emit another die into the global context. 
This one has line 6.  Then when we handle the function main, we see the inlined
version of f, and we get a decl of i with an abstract origin pointing at the
function f, and emit two more dies, one local one in the inlined version of f
that points at the abstract instance of f, and one global one that also points
at the abstract instance of f.  This last one is very wrong.  Note that there
are 5 dies not 4 as I claimed earlier, I missed the one in 'main' when I was
counting them.

It seems very silly to try to emit a namespace version of a decl with an
abstract origin.  One possible solution is for declare_in_namespace to ignore
any decl with an abstract origin.  If I try this, I get only 4 dies, and gdb is
happy.  We still have two global dies, with different line numbers, but we can
live with that for now.

I haven't yet tried to trace the history of this, to determine what change
caused the problem to appear.  There might be something else wrong here.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb

[dberlin at dberlin dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2005-03-16 04:25 -------
Subject: Re:  [4.0/4.1 Regression] GCC produces wrong dwarf2
	output that breaks gdb

On Wed, 2005-03-16 at 03:54 +0000, wilson at gcc dot gnu dot org wrote:
> ------- Additional Comments From wilson at gcc dot gnu dot org  2005-03-16 03:54 -------
> Part of the problem here is the way that declare_in_namespace works. 
> gen_variable_die, calls declare_in_namespace, which checks to see if the
> variable has a namespace, and if so emits it into that namespace. 
> declare_in_namespace then returns, and gen_variable_die finishes normally, which
> means we end up with DIEs for one variable.  The local one in the current
> context, and the one emitted into the namespace.  The variable in question here
> has a namespace of "::".
> 
> When we process the abstract instance of f, we emit a local die for i into f,
> and a namespace one into :: the global context.  This one has line 3.  Then we
> see the global redeclaration, and emit another die into the global context. 
> This one has line 6.  Then when we handle the function main, we see the inlined
> version of f, and we get a decl of i with an abstract origin pointing at the
> function f, and emit two more dies, one local one in the inlined version of f
> that points at the abstract instance of f, and one global one that also points
> at the abstract instance of f.  This last one is very wrong.  Note that there
> are 5 dies not 4 as I claimed earlier, I missed the one in 'main' when I was
> counting them.
> 
> It seems very silly to try to emit a namespace version of a decl with an
> abstract origin.  One possible solution is for declare_in_namespace to ignore
> any decl with an abstract origin.  If I try this, I get only 4 dies, and gdb is
> happy.  We still have two global dies, with different line numbers, but we can
> live with that for now.
> 
I'm pretty sure declare_in_namespace was something either jason wrote
with my help, or i wrote with jason's help (i can't remember), and i'm
pretty sure this problem didn't occur to either of us.

I agree that  outputting a namespace version of an inline die with an
abstract origin is indeed silly, since i don't believe it could possibly
be the one that actually belongs in that namespace (which would be
whatever the actual abstract origin points to).


> I haven't yet tried to trace the history of this, to determine what change
> caused the problem to appear.  There might be something else wrong here.
> 



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb

[bothner at gcc dot gnu dot org]

------- Additional Comments From bothner at gcc dot gnu dot org  2005-03-17 19:17 -------
(In reply to comment #18)
I tried Jim's patch, and it seems to work.
(I haven't done a full-boostrap, but I compiled jc1, cc1plus, and libjava, and
re-installed them.)
I then re-compiled Kawa, and I seem to be able to debug.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb

[wilson at gcc dot gnu dot org]

------- Additional Comments From wilson at gcc dot gnu dot org  2005-03-18 06:05 -------
I got four additional gdb testsuite failures with the patch.  I will have to
figure out what went wrong, and then rebuild and retest.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-19 03:07 -------
Subject: Bug 19769

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	wilson@gcc.gnu.org	2005-03-19 03:06:52

Modified files:
	gcc            : ChangeLog dwarf2out.c 

Log message:
	Fix problem that caused compiled java code to trigger an internal gdb error.
	PR c++/19769
	* dwarf2out.c (declare_in_namespace): Ignore decls with an abstract
	origin.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7907&r2=2.7908
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gcc&r1=1.571&r2=1.572



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb

[dberlin at dberlin dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2005-03-19 03:50 -------
Subject: Re:  [4.0/4.1 Regression] GCC produces wrong dwarf2
	output that breaks gdb

On Sat, 2005-03-19 at 03:07 +0000, cvs-commit at gcc dot gnu dot org
wrote:
> ------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-19 03:07 -------
> Subject: Bug 19769
> 
> CVSROOT:	/cvs/gcc
> Module name:	gcc
> Changes by:	wilson@gcc.gnu.org	2005-03-19 03:06:52
> 


Just FYI (Maybe you are and the log message hasn't been processed by
bugzilla yet), this needs to go on the 4.0 branch as well, since the bug
exists there too.

Thanks so much for fixing this bug.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug c++/19769] [4.0 Regression] GCC produces wrong dwarf2 output that breaks gdb

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-19 05:27 -------
Fixed at least on the mainline (for 4.1).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.0/4.1 Regression] GCC    |[4.0 Regression] GCC
                   |produces wrong dwarf2 output|produces wrong dwarf2 output
                   |that breaks gdb             |that breaks gdb


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug c++/19769] [4.0 Regression] GCC produces wrong dwarf2 output that breaks gdb

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-23 03:11 -------
Subject: Bug 19769

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	wilson@gcc.gnu.org	2005-03-23 03:10:58

Modified files:
	gcc            : ChangeLog dwarf2out.c 

Log message:
	Fix problem that caused compiled java code to trigger an internal gdb error.
	PR c++/19769
	* dwarf2out.c (declare_in_namespace): Ignore decls with an abstract
	origin.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.79&r2=2.7592.2.80
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.570.2.2&r2=1.570.2.3



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug c++/19769] [4.0 Regression] GCC produces wrong dwarf2 output that breaks gdb

[wilson at gcc dot gnu dot org]

------- Additional Comments From wilson at gcc dot gnu dot org  2005-03-23 03:15 -------
May as well take it, seeing as how I wrote a patch for it.

The gdb failures do not seem related to my change, and when I reran the gdb
testsuite, they disappeared.  I don't know what happened, but as far as I am
concerned the patch has passed the test and I'm checking it in.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |wilson at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2005-02-02 23:50:07         |2005-03-23 03:15:13
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769

[Bug c++/19769] [4.0 Regression] GCC produces wrong dwarf2 output that breaks gdb

[wilson at gcc dot gnu dot org]

------- Additional Comments From wilson at gcc dot gnu dot org  2005-03-23 03:20 -------
My net connection died when trying to check in the patch, and it was a Friday
evening...

I'm a little surprised that the mainline check in actually worked.  I thought it
hadn't.  I've also added it to the 4.0 branch now.

Fixed on mainline and the gcc-4.0 branch.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769