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] |
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.
Yup.
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |