breakpoints in constructors

[Daniel Berlin]

On Wednesday, April 30, 2003, at 10:43  AM, Michael Elizabeth Chastain 
wrote:

> 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.

It was just a "it's simple to implement this way, we'll optimize it 
later" thing, i think.
You know, of the "why not keep the ABI implementation simple before we 
make it buggy" thought? :P
>
>> 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?
>
Yup.
But i was thinking that the problem with a flattened tree like that is 
that it requires more work when checking breakpoints, which can be 
expensive
See, we can easily test whether we are possibly within the range of a 
level 1 breakpoint by keeping track of the upper/lower bounds, even in 
your scheme (I say possibly since it could be multiple disjoint ranges, 
so we mihgt not *really* be in the bounds, but it's an optimization to 
not look at 2+ level breakpoints to see which we hit when it's 
impossible that we hit any of them)

However, in your case, we'll need a linear walk of all the level 2+ to 
determine whether we are in range of any of them. O(n)
If it's still organized as a multi-level binary tree (kept in some sort 
of sorted order), we only have to check log N of the breakpoints.
If you breakpoint a heavily constructed object and set a condition on 
it, we might hit this thing a billion times, so it can add up quickly.

>> ... (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.

I thought of a separate use of a BP hierarchy yesterday, which is 
handling inlined code (since it also may appear in multiple places, and 
if the user breaks on a source line that's inlined, he wants it to stop 
in all the copies)
It led me just now to think of a use case: Inlined code in Inlined code.
In that case, you *could* flatten the tree into 2 levels, but it's 
easier to build it as a subtree of a subtree (since we do a lot of 
debug reading recursively, and don't know where we came from), so 
unless the flattening was done in the l2breakpoint_add or whatever 
automatically, this might be problematic.


>
>> (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