[LLVMbugs] [Bug 13317] Debug information for inline constructor not proper.

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=13317

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID

--- Comment #6 from Douglas Gregor <dgregor at apple.com> 2012-07-16 10:02:54 CDT ---
(In reply to comment #5)
> Dear Eric,Douglas
> Thanks for the quick reply. I had one quick query.
> 
> As Douglas mentioned 'C1' name is the complete object constructor and the 'C2'
> name is the base object constructor. But in the example
> 
> class Apple
> {
> public:
>  Apple ()
>     {
>       int b = 0;
>     }
> };
> 
> int
> main (void)
> {
>   Apple b;
>   return 0;
> }
> 
> This class has no base. Why does it have a "complete object constructor" and a
> "base object constructor" for each?

The Itanium C++ ABI I linked to describes this in detail, but essentially the
"complete object constructor" is used when we're building a complete object of
type Apple, as in

  Apple a;

while the "base object constructor" is used when the Apple object is a base of
another class, e.g.,

  class Banana : public Apple { }; 
  Banana b;

> This dual emission of constructor results in problem with setting breakpoints
> in constructors as we have two info for same location.
> 
> For e.g.
> In the above code if we run the gdb session as follows-
> 
> 
> /opt/home/blitz # gdb a.out 
> GNU gdb (Linaro GDB) 7.2-2011.03-0-SLP
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "arm-linux-gnueabi".
> For bug reporting instructions, please see:
> <http://bugs.launchpad.net/gdb-linaro/>...
> Reading symbols from /opt/home/blitz/a.out...done.
> (gdb) b main
> Breakpoint 1 at 0x83ca: file ./class.cpp, line 13.
> (gdb) b 6
> Breakpoint 2 at 0x8406: file ./class.cpp, line 6.
> (gdb) r
> Starting program: /opt/home/blitz/a.out 
> 
> Breakpoint 1, main () at ./class.cpp:13
> warning: Source file is more recent than executable.
> 13        Apple a;
> (gdb) c
> Continuing.
> 
> Breakpoint 2, Apple::Apple (this=0xbe811ab8) at ./class.cpp:6
> 6            int b = 0;
> (gdb) bt
> #0  Apple::Apple (this=0xbe811ab8) at ./class.cpp:6
> #1  0x000083f2 in Apple::Apple (this=0xbe811ab8) at ./class.cpp:7
> #2  0x000083d8 in main () at ./class.cpp:13
> (gdb) Quit
> (gdb) 
> 
> 
> In the above session we can find that we had set break point at line 6 and have
> not yet reached line 7. But the  bt command when run at line 6 also emits the
> wrong info -
> #1  0x000083f2 in Apple::Apple (this=0xbe811ab8) at ./class.cpp:7
> (line 7 info which comes from C1 constructors prologue_end .loc)
> 
> There are few other GDB problems as well when we debug the constructor.
> 
> 
> When we looked up we found that the same issue was reported in case of GCC. 
> We can refer-
> 
> http://stackoverflow.com/questions/6921295/dual-emission-of-constructor-symbols
> http://gcc.gnu.org/bugs/#known,

Personally, I don't consider this a bug in either GCC or Clang. This behavior
is mandated by the Itanium C++ ABI, and it's GDB that needs to learn to handle
C++ constructors emitted for the Itanium C++ ABI properly.

> When we checked the same in case of gcc it seems it actually alias the symbols
> to the same code for both.
> A temporary patch seems to have been given as per
> http://sources.redhat.com/ml/gdb/2004-07/msg00163.html
> 
> We might need to do something similar in case of clang. Please let us know if
> our analysis is correct. 

Clang does perform this optimization on some platforms, when possible. However,
it can't always be done (because the constructors will behave differently when,
e.g., there are virtual base classes involved), and therefore can't be relied
upon to improve the debugging situation.

Unless Eric thinks there is something specific that the compiler can do here
(which I doubt), I think this is not a Clang bug.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.