This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Breakpoints in constructors, when will they work?
- From: Michael Veksler <mveksler at techunix dot technion dot ac dot il>
- To: gdb at sourceware dot org
- Date: Thu, 31 Aug 2006 14:12:31 +0300
- Subject: Breakpoints in constructors, when will they work?
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