This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: breakpoints in constructors



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]