Re: breakpoints in constructors

[Michael Elizabeth Chastain <mec@shout.net>]

Hi Daniel,

> It's not required multi-object-code, it's only required that it does 
> the right thing when called with a certain name  (not the same at all, 
> since one can  just make up the symbols for the constructors that start 
> at the right points in the "one object code constructor" function, 
> without even having to make stub functions with gotos in them. Just 
> multiple symbol names and one object code).

I see what you mean.  The ABI requirements are that there be two or three
labels, and that the labels have different semantics.  It was just an
assumption on my part that C++ compilers always emit distinct,
single-entry-point functions.

> One way is to make one "visible" breakpoint and 2 "hidden" breakpoints.
> This is a bit ugly, unless you special case the breakpoint printouts so 
> that it says the one "visible" breakpoint is at pc x, y, z, rather than 
> just x (the code to do this is probably ugly too in this method).

This is possible but I am really not into this approach.

I would rather expose to the user that one block of source code really
does generate several blocks of object code, and then handle constructors
and destructors in a similar way that we handle inline functions.
After one initial surprise ('how come gdb sets 2-3 breakpoints when I
break on a constructor'), I think that users would actually understand
this model pretty well.

> You could also just make a hierarchy of breakpoints and avoid the magic 
> methods and hiding altogether.
> You have one parent breakpoint named "Foo:Foo" that just consists of 3 
> sub-breakpoints, each at the right place in the constructor.

Yeah.  You call them hierarchical, but I think of them as different
types.  The 'parent' here is of type 'source breakpoint'.  The
'subs' are of type 'object code breakpoint'.

The current model is that a 'source breakpoint' and an 'object code
breakpoint' have a 1-1 relationship.  We could separate the types and
then a source breakpoint could have a 1-many relationship with a
list of object code breakpoints.

So your vision is a tree of nodes, all of the same type, and my vision
is of fixed depth 2, where level 1 is type SB, and level 2 is type OCB.
An SB has a list of OCB's and that's the whole structure.

Is this making sense?

> ... (since i imagine in some extremely complex case, one could want to
> have a subbreakpoint consisting of subbreakpoints) ...

Mmmmm, what would be a use case for that?  If there is a real use case
than my simple two-level structure would be inadequate.

> (You can either just make it print "exists at multiple pc's, or recursively 
> print out the pc's of the sub breakpoints).
> 
> Hitting one of the subbreakpoints doesn't require any magic, since what 
> we say is that we've hit the parent breakpoint, "Foo:Foo".

Yes, this sounds good to me.  Again in terms of "source breakpoint"
and "object code breakpoint", it becomes very simple:

  by definition, only an object code breakpoint can actually be executed
  gdb usually translates the OCB back to a SB for display

Michael C