Breakpoints in constructors, when will they work?

[Michael Veksler <mveksler at techunix dot technion dot ac dot il>]

Hello GDB developers,

Are there any plans to fix the issue of breakpoints in constructors and 
destructors?

Reminder:
This issue is was introduced with gcc-3.0 when a new ABI was adopted. In 
this new ABI the same constructor code is emitted multiple times with 
different mangled names. This was one of the possible solutions to 
construct an object that has a virtual inheritance. Different 
constructor variants either build the virtual parent, or they don't. 
Before gcc-3.0, a hidden argument was used to tell the single 
constructor what to do. (IIRC there is a third constructor kind).

There is a patch floating around that gives different names to the 
different constructor variants:
(A::A$base()  and A::A() ).
This patch was applied by whoever installed my RHEL4 (could well be 
RedHat). It is ugly, and annoying but better than having breakpoints 
silently "ignored". Why wasn't it put in the official GDB? One of the 
PRs says that $base trick is confusing the users with low level details, 
and I concur. But having GDB nondeterministically ignore breakpoints 
confuses  and annoys  even more.

To minimize confusion about $base, it is possible to add a flag that 
will hide the $base constructors from users (which will be the default). 
The $base constructors are needed only for debugging constructors with 
multiple virtual inheritance. 99% of the cases the users will not need 
to deal with $base, and it could be hidden. The advantage of hiding 
$base from the user is that the most commonly needed constructor will be 
affected (regular constructor) without confusing the user. Without this 
patch, a constructor is used at random. Sometimes the "in charge" is 
used and sometimes the "not in charge", this is confusing and frustrating.

There was a talk of a "correct" fix to the problem - one logical 
breakpoint with multiple physical breakpoints. This was supposed to fix 
other problems like multiply inlined functions. Users don't care if a 
function was inlined or not, they want to set a breakpoint at line 123 
of that function. Future versions of gcc will duplicate functions, a 
fact the user is not interested to know. This requires a substantial 
infrastructure work, and probably some interface decisions.

The correct feature is not fully opposite of the ugly workaround. Even 
with the correct feature the user will be aware of the existence of 
multiple constructor variants. When a user requests "info breakpoints" 
what address will gdb present? A list of addresses?

Are there any plans to either integrate the ugly workaround or to 
implement the correct feature? Any change would be much better than the 
current situation.

--
 Michael