Bug 150693 - [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb
[4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gcc4 (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
http://gcc.gnu.org/bugzilla/show_bug....
:
Depends On:
Blocks: 116894
  Show dependency treegraph
 
Reported: 2005-03-09 14:11 EST by Andrew Cagney
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version: 4.0.0-0.36
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-05 07:38:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 19769 None None None Never

  None (edit)
Description Andrew Cagney 2005-03-09 14:11:37 EST
From upstream bug:

The combination of libjava/include/posix-threads.h and
libjava/posix-threads.cc
combine to produce broken dwarf2 output when compiled with
optimization and -g.
(This can be seen by bootstrapping, installing, then running a recent
gdb on
either gij, or libgcj.so)

The cause is this:
in posix-threads.h:

inline _Jv_Thread_t *
_Jv_ThreadCurrentData (void)
{
  extern pthread_key_t _Jv_ThreadDataKey;
  return (_Jv_Thread_t *) pthread_getspecific (_Jv_ThreadDataKey);
}


in posix-threads.cc

pthread_key_t _Jv_ThreadDataKey;

We end up with calls to _Jv_ThreadCurrentData before we get to output
debug info
for _Jv_ThreadDataKey (which is a perfectly reasonable turn of events).

We end up generating a full die for _Jv_ThreadDataKey inside
_Jv_ThreadCurrentData

We then go to output the global, and mark it as having an abstract
origin of the
DIE inside the inlined function.
This is backwards.

I'm not sure how easy/hard this will be to fix. 
The obvious thing to do is to drive global variable debug output using
cgraph,
but that seems a bit invasive for 4.0.
I'm also sure this patch exposed by one of my patches to mark blocks
properly,
which in turn fixed other regressions, so I don't believe we should simply
revert them.

It's possible that the DECL_ABSTRACT_ORIGIN's aren't set up properly,
and that
is the real cause here.  I would have expected we would have seen that the
declaration inside the inline had an abstract origin of the one
outside the
inline, and thus, we wouldn't have tried to output a full die for it,
but this
isn't what appears to happen.
Comment 1 Jakub Jelinek 2005-03-09 14:25:26 EST
gcc-4.0.0-0.3* has gcc4-pr19769-workaround.patch patch in it so that this bug
isn't triggered on the installed libgcj.so.
Comment 2 Jakub Jelinek 2005-04-05 07:38:53 EDT
PR19769 is fixed in 4.0.0-0.36 and above.

Note You need to log in before you can comment on or make changes to this bug.