Re: breakpoints in constructors

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Apr 18, 2003 at 01:04:46PM -0700, David Carlton wrote:
> I might have some time over the next few weeks (/months) to work on
> the "breakpoints in constructors" issue.  Daniel: clearly you've
> thought about this already, so if you happen to have time to do a bit
> of a brain dump on the issue at some point, I'd appreciate it.

Sure.  First of all, a rough overview of the problem; might as well
keep everything in one place.

With the new GCC 3.x multi-vendor C++ ABI, constructors are implemented
as multiple functions:
  C1, the complete object constructor [in-charge]
  C2, the base object constructor [not-in-charge]
  C3, the allocating constructor [not currently used]

Similarly for destructors - most of the rest of this message applies to
destructors too.  The base constructor is generally called for the base
objects of a derived class, esp. with virtual inheritance; it's been a
while since I looked at exactly when.

GCC has chosen to implement this by duplicating the function, including
any user-provided code and any compiler-added code.  A better
implementation would have one copy and labels for multiple entry
points, on systems where that is supported; that's temporarily tabled
pending a better description of the GCC tree structure to describe
multiple entry points.

So the end result is that we start with:
class C {
  public: C();
};

C::C()
{
  // do stuff
}

And there are two copies of that function.  If we use the demangler in
non-verbose mode, we get the same demangled name for both of them:
C::C().  If we use it in verbose mode we get C::C[in-charge]() and
C::C[not-in-charge](), but using verbose mode has other issues for GDB;
it's too verbose/obscure in some places.

So there are two interesting problems:
  - What happens when I say "break C::C"?
  - What happens when I say "break <line>", pointing at the "do stuff"?

So that's the general problem.


Ideally, when we say "break C::C" we will get multiple breakpoints
automatically.  Not to be confused with find_methods/decode_line_2!
We'd still get a menu with two choices if there was a copy constructor
and a default constructor; but choosing either one would place two
breakpoints.

What would this mean for "info breakpoints"?  Would they be one
breakpoint with multiple addresses or visible to the user as two
breakpoints?  I'd prefer the former but I believe there was some
disagreement.  I don't know what current art in other debuggers is;
does anybody?

Similarly when we say "break line", IMO, there should be multiple
breakpoints.  This is even harder; in optimized code we may have
multiple ranges of PC for a particular line even in the same function
(and IMO we should be placing more than one breakpoint in that case);
here we have multiple ranges across different functions.  Placing one
user-visible breakpoint per range would get out of hand pretty fast. 
With the current breakpoint implementation even placing all the
breakpoints would get out of hand pretty fast, since we remove all
breakpoints from memory at each stop.  I think that's fixable.

[Assuming an improved breakpoint layer, can we place a breakpoint on
every possible instruction in a line?  With variable-length
instructions this is very hard; with jump tables in text sections it
might be downright impossible, since we don't know what is code and
what isn't.  Placing a breakpoint at the beginning of every distinct
range, while not perfect, is still an improvement.

However, it's kind of confusing.  Stepping through optimized code you
might hit the "one" breakpoint multiple times.  Bears some thinking
about.]

All of this eventually ties in to debugging inlined functions and
templated functions, which are harder versions of the same thing.

Can't think of anything else at the moment...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer