breakpoints in C++ constructors

breakpoints in C++ constructors

[Jim Blandy]

I've been spending some time looking into getting breakpoints in C++
constructors to work right, but I don't have much to say about it yet.
But if there are other people who have thoughts about this, let's talk
about it.

The essential problem is that a single source construct --- a
constructor body for some class C --- gets split into two separate
machine-language functions: one to be used when constructing a direct
instance of class C (the "in charge" constructor), and one to be used
when constructing an instance of some class derived from C (the "not
in charge" constructor), to initialize the portion of the object that
corresponds to the C subclass.

In the following thread, Daniel Jacobowitz and Michael Chastain talked
about the user interface implications of constructing distinct names
for the two instances of the constructor:

   http://sources.redhat.com/ml/gdb/2004-07/msg00161.html

Daniel has done some work on the breakpoint code to separate the
structures that track machine-level breakpoints (either hardware
support or patched instructions) from user-level breakpoints.  The
original intention was to extend this to allow a single user
breakpoint to cover multiple machine-code locations, but that change
hasn't been made yet: the code still assumes a one-to-one
relationship.  Completing this would be the natural way to support
constructor breakpoints.  The MI format for breakpoints would need to
change to report the addresses as a list, and the test cases adapted
accordingly.

The symbol table code would need to be adapted to return multiple
addresses for a given source location.  Since a given source line can
be split into many runs of machine code, a source line may, in
general, appear any number of times in the line tables; we currently
just return the first entry we find, and hope that's appropriate.  To
accomodate constructors, we might consider returning a sal for the
first line table entry for a given source location in each machine-
level function: if a given source line appears nine times in three
separate machine-level functions, we could return a list of three
sals reporting the first occurrence of the line in each function.

Re: breakpoints in C++ constructors

[Daniel Jacobowitz]

On Tue, Sep 14, 2004 at 11:06:51AM -0500, Jim Blandy wrote:
> The symbol table code would need to be adapted to return multiple
> addresses for a given source location.  Since a given source line can
> be split into many runs of machine code, a source line may, in
> general, appear any number of times in the line tables; we currently
> just return the first entry we find, and hope that's appropriate.  To
> accomodate constructors, we might consider returning a sal for the
> first line table entry for a given source location in each machine-
> level function: if a given source line appears nine times in three
> separate machine-level functions, we could return a list of three
> sals reporting the first occurrence of the line in each function.

I think we would want to take inline instances into account here; even
before we support other aspects of inlining, the "source line" is
logically distinct each time it is inlined.

Everything else looked reasonable to me.

-- 
Daniel Jacobowitz

Re: breakpoints in C++ constructors

[Andrew Cagney]

> In the following thread, Daniel Jacobowitz and Michael Chastain talked
> about the user interface implications of constructing distinct names
> for the two instances of the constructor:
> 
>    http://sources.redhat.com/ml/gdb/2004-07/msg00161.html

It's important that we view these as separate problems:

- a mechanism for explicitly specifying either of the in-charge or 
not-in-charge constructor

- a mechanism for specifying the "constructor" (meaning all)

I think users want both, and would be over the moon, if they just got 
the first (that's the polite translation).

With regard to N:M, note:
http://sources.redhat.com/ml/gdb/2004-05/msg00060.html

I've also a fuzzy recolection of code like this being added once before, 
only to be later removed - would you recall the problems with that?

--

However, I think we need to first wack down our debuginfo backlog.

Andrew

Re: breakpoints in C++ constructors

[Paul Koning]

>>>>> "Andrew" == Andrew Cagney <cagney@gnu.org> writes:

 >> In the following thread, Daniel Jacobowitz and Michael Chastain
 >> talked about the user interface implications of constructing
 >> distinct names for the two instances of the constructor:
 >> 
 >> http://sources.redhat.com/ml/gdb/2004-07/msg00161.html

 Andrew> It's important that we view these as separate problems:

 Andrew> - a mechanism for explicitly specifying either of the
 Andrew> in-charge or not-in-charge constructor

 Andrew> - a mechanism for specifying the "constructor" (meaning all)

 Andrew> I think users want both, and would be over the moon, if they
 Andrew> just got the first (that's the polite translation).

I'm not sure what that means.  But in any case, I'd like to have #1
for a start, because right now I have nothing.  (Well, unless I do
what I did before, which is to turn on the "verbose" flag in the
demangler as a hack, so the two constructors and the three destructors
have different names.)

     paul

Re: breakpoints in C++ constructors

[Jim Blandy]

There are some simpler problems whose solution would make supporting
C++ constructors a bit easier.

For example, what if we first tried to get this case working:


foo.c:

#include <stdio.h>

int
f1 (int x)
{
#include <body.h>        
}

int
f2 (int x)
{
#include <body.h>
}

int
main (int argc, char *argv)
{
  printf ("%d\n", f2 (f1 (1)));
}


body.h:
return x * 2;


Setting a breakpoint at body.h:1 ought to result in breakpoint hits in
f1 and f2.  Making this work requires addressing:

- symtab issues: decode_all_digits needs to return all the locations.
  etc. 

- user interface issues: How do we list breakpoints with multiple
  address?  How do they appear in MI?

- mechanism issues: we have to get breakpoint insertion and removal
  right.  If the breakpoint is conditional, we need separate parsed
  versions of the condition for each location, since each location's
  expression is (potentially) being evaluated in a different block.
  etc. 

I think getting this working would make breakpoints by source location
in constructors work: it's the same source location appearing in more
than one physical function.

Re: breakpoints in C++ constructors

[Paul Gilliam]

On Tuesday 14 September 2004 09:06, Jim Blandy wrote:
 -- snip --
> Daniel has done some work on the breakpoint code to 
 -- snip --
> The original intention was to extend this to allow a single user
> > breakpoint to cover multiple machine-code locations, but that change 
> hasn't been made yet: the code still assumes a one-to-one
> relationship.  Completing this would be the natural way to support
> constructor breakpoints. 

If one breakpoint could cover multiple machine-code locations, then that 
mechanizm could be use for the requested new "break at all functions" 
command.  

-=# Paul Gilliam #=-