public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/25793]  New: dwarf2 debug info lacks linkage names for constructors & destructors
@ 2006-01-15 14:15 thor at math dot tu-berlin dot de
  2006-01-15 16:19 ` [Bug debug/25793] " pinskia at gcc dot gnu dot org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: thor at math dot tu-berlin dot de @ 2006-01-15 14:15 UTC (permalink / raw)
  To: gcc-bugs

g++-4.0.1 (also reproduced with g++-3.4.4) fails to add the linkage name of the
class constructor to the debugging info, making it impossible to set
breakpoints in classes containing more than one constructor (e.g. with gdb).

How to reconstruct: Save the following as test.hpp:

class TestClass {
  int y;
public:
  int funcA(void);
  TestClass(int x);
  ~TestClass(void);
};

Save the following as test.cpp:

#include "test.hpp"

int TestClass::funcA(void)
{
  return y;
}

TestClass::TestClass(int x)
  : y(x)
{
}

TestClass::~TestClass(void)
{
}

int main(void)
{
  TestClass a(0);

  return a.funcA();
}

Compile g++ test.cpp -ggdb3 -O0, then check the debugging information with
dwarfdump. Here's the important section:
<2><  105>      DW_TAG_subprogram
                DW_AT_sibling               <153>
                DW_AT_external              yes(1)
                DW_AT_name                  funcA
                DW_AT_decl_file             2 /home/thor/test.hpp
                DW_AT_decl_line             4
                DW_AT_MIPS_linkage_name     _ZN9TestClass5funcAEv
                DW_AT_type                  <208>
                DW_AT_declaration           yes(1)
<3><  146>      DW_TAG_formal_parameter
                DW_AT_type                  <215>
                DW_AT_artificial            yes(1)
<2><  153>      DW_TAG_subprogram
                DW_AT_sibling               <178>
                DW_AT_external              yes(1)
                DW_AT_name                  TestClass
                DW_AT_decl_file             2 /home/thor/test.hpp
                DW_AT_decl_line             5
                DW_AT_declaration           yes(1)
<3><  166>      DW_TAG_formal_parameter
                DW_AT_type                  <215>
                DW_AT_artificial            yes(1)
<3><  172>      DW_TAG_formal_parameter
                DW_AT_type                  <208>

As seen from the above, member functions do get the full debugging info,
including the mangled name (linkage name), but the constructor does not. This
gets worse in case more than one constructor is available since gdb is then no
longer able to find the entry point.


-- 
           Summary: dwarf2 debug info lacks linkage names for constructors &
                    destructors
           Product: gcc
           Version: 4.0.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: thor at math dot tu-berlin dot de
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug debug/25793] dwarf2 debug info lacks linkage names for constructors & destructors
  2006-01-15 14:15 [Bug debug/25793] New: dwarf2 debug info lacks linkage names for constructors & destructors thor at math dot tu-berlin dot de
@ 2006-01-15 16:19 ` pinskia at gcc dot gnu dot org
  2006-01-16  9:29 ` thor at math dot tu-berlin dot de
  2006-01-17 20:24 ` pinskia at gcc dot gnu dot org
  2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-01-15 16:19 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from pinskia at gcc dot gnu dot org  2006-01-15 16:19 -------
HUH????  The linkage_name is not needed for gdb, well it should not be needed. 
This is also a dup of bug 11774 which has a better description of why
linkage_name is going away.

Also I tried with a newer gdb (6.3.50.20051027) and it worked with this
testcase and also with a class like:
class TestClass {
  int y;
public:
  int funcA(void);
  TestClass(int x);
  ~TestClass(void);
  TestClass();
};

And I could set the breakpoint:
(gdb)  b TestClass::TestClass(int)
Breakpoint 1 at 0x804835b: file t.cc, line 20.
(gdb) b TestClass::TestClass()
Breakpoint 2 at 0x80483bd: file t.cc, line 10.

*** This bug has been marked as a duplicate of 11774 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug debug/25793] dwarf2 debug info lacks linkage names for constructors & destructors
  2006-01-15 14:15 [Bug debug/25793] New: dwarf2 debug info lacks linkage names for constructors & destructors thor at math dot tu-berlin dot de
  2006-01-15 16:19 ` [Bug debug/25793] " pinskia at gcc dot gnu dot org
@ 2006-01-16  9:29 ` thor at math dot tu-berlin dot de
  2006-01-17 20:24 ` pinskia at gcc dot gnu dot org
  2 siblings, 0 replies; 4+ messages in thread
From: thor at math dot tu-berlin dot de @ 2006-01-16  9:29 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from thor at math dot tu-berlin dot de  2006-01-16 09:29 -------
HI Andrew,

even though I'm not sure whether this is a duplicate of 11774 (I'm not
competent enough to judge that), let me explain:

i) The reason why you are able to set a breakpoint here is the consequence of
the testclass having only one single (non-trivial) constructor and no base
class. The problem becomes aparent as soon as you add a second (non-trivial)
constructor and call "the wrong one", i.e. one that gdb is not aware of. As far
as I know, g++ generates more than one subroutine per constructor (is this
correct?) and gdb does not know *where* to set the breakpoint. Unfortunately,
the program where this happens here is a bit too large, and this also seems to
some part a bug in gdb.

ii) I've worked thru the gdb code last weekend. gdb does, indeed, depend on the
mangled symbol name in the dwarf output as otherwise it seems to be unable to
locate the proper symbol. It stores the linkage name ("physname" there in
gdb-speak) in its data structure, and then later uses this name to locate the
proper code section. However, at that time, it is already too late to
distinguish between the two constructors. The gdb version I'm using is the
latest, gdb 6.4, pulled off the gdb web-page. Indeed, gdb should use the
additional attributes provided with the symbol to locate the code, though it
doesn't. I don't know about the gdb authors, but it looks hard to fix this
right now, and adding the linkage name *might* help a lot here. (At least, I
was trying to fix gdb for my in-house use then to provide a patch for gdb, but
failed due to that.)

If that helps, I'll try to construct a larger non-trivial test case for it (but
then larger really means that) the bug becomes pretty anoying for a project I'm
working on, making it impossible to set breakpoints in constructors).

So long,
Thomas


-- 


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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug debug/25793] dwarf2 debug info lacks linkage names for constructors & destructors
  2006-01-15 14:15 [Bug debug/25793] New: dwarf2 debug info lacks linkage names for constructors & destructors thor at math dot tu-berlin dot de
  2006-01-15 16:19 ` [Bug debug/25793] " pinskia at gcc dot gnu dot org
  2006-01-16  9:29 ` thor at math dot tu-berlin dot de
@ 2006-01-17 20:24 ` pinskia at gcc dot gnu dot org
  2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-01-17 20:24 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #3 from pinskia at gcc dot gnu dot org  2006-01-17 20:23 -------
(In reply to comment #2) 
> i) The reason why you are able to set a breakpoint here is the consequence of
> the testclass having only one single (non-trivial) constructor and no base
> class. The problem becomes aparent as soon as you add a second (non-trivial)
> constructor and call "the wrong one", i.e. one that gdb is not aware of. As far
> as I know, g++ generates more than one subroutine per constructor (is this
> correct?) and gdb does not know *where* to set the breakpoint. Unfortunately,
> the program where this happens here is a bit too large, and this also seems to
> some part a bug in gdb.

That is fully a gdb bug as mentioned before in different places, I think there
is a gdb bug about it too.

The problem is that gdb does not know which constructor (the in charge or the
out of charge one) to place the breakpoint so it chooses one, the wrong one in
your case.


-- 


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


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-01-17 20:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-15 14:15 [Bug debug/25793] New: dwarf2 debug info lacks linkage names for constructors & destructors thor at math dot tu-berlin dot de
2006-01-15 16:19 ` [Bug debug/25793] " pinskia at gcc dot gnu dot org
2006-01-16  9:29 ` thor at math dot tu-berlin dot de
2006-01-17 20:24 ` pinskia at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).