Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

[Michael Elizabeth Chastain]

Jason Merrill writes:
> The thing is, we want the debugger to treat them as the same function, so
> that setting a breakpoint on the signature actually sets one on each and
> the like.

I for one do not want that to happen at all!

There really are two bodies of code in the target program code.
The compiler emits two bodies of code; the linker recognizes two bodies
of code with different names.

Consider this code:

  class C1 { public: C1::C1(); };
  C1::C1 () { foo(); bar(); bletch(); }

Suppose the user sets a breakpoint in foo(), looks at the stack,
and sees the name C1::C1().  They decide they want to read the machine
language instructions for the constructor, so they type "disass C1::C1".
What do you want gdb to do?

I would like gdb to demangle different names differently.  Perhaps:

  (gdb) ptype C1
    ... C1::C1 ...
    ... C1::C1$base ...

... where the first line is for the in-charge constructor, and the second
line is for the not-in-charge constructor.  Then the user can disassemble,
breakpoint, and call whichever function they want (they better know what
they are doing if they call a not-in-charge constructor by hand though).
If they don't know what C1::C1$base is, they can read a document, where
they can learn that each constructor and destructor in the source code is
compiled to multiple object functions in the object code, with different
interfaces and purposes.

As to how this relates onto symbol handling, I don't know.  I just know
that I want names that reflect reality in ptype, disassmble, break,
and backtrace.

Michael C

Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

[Jason Merrill]

>>>>> "Michael" == Michael Elizabeth Chastain <mec@shout.net> writes:

> I would like gdb to demangle different names differently.

Which brings me to a question: Why don't we demangle them differently?
Currently, flag_verbose in cp-demangle.c defaults to 0, so the two
functions are demangled identically.  I think this is wrong, and have
changed flag_verbose to 1 for my own use.  What do other people think?

Jason

Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

[Daniel Berlin]

On Tue, 4 Dec 2001, Jason Merrill wrote:

> >>>>> "Michael" == Michael Elizabeth Chastain <mec@shout.net> writes:
>
> > I would like gdb to demangle different names differently.
>
> Which brings me to a question: Why don't we demangle them differently?
> Currently, flag_verbose in cp-demangle.c defaults to 0, so the two
> functions are demangled identically.  I think this is wrong, and have
> changed flag_verbose to 1 for my own use.  What do other people think?

IIRC, the reason was that ptype output should be directly usable in the
target language.
We had a large discussion about this sometime in the past year, i can't
quite remember the outcome.
I had a patch to gdb/libiberty that passed DMGL_VERBOSE along (and added
DMGL_VERBOSE to the flags) for this purpose.

>
> Jason
>

Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

[Daniel Jacobowitz]

On Tue, Dec 04, 2001 at 01:26:47PM +0000, Jason Merrill wrote:
> >>>>> "Michael" == Michael Elizabeth Chastain <mec@shout.net> writes:
> 
> > I would like gdb to demangle different names differently.
> 
> Which brings me to a question: Why don't we demangle them differently?
> Currently, flag_verbose in cp-demangle.c defaults to 0, so the two
> functions are demangled identically.  I think this is wrong, and have
> changed flag_verbose to 1 for my own use.  What do other people think?

Strongly agree.  I was boggled to find two names for obviously
different constructors that were demangled to the same thing; after
figuring out what all the different variants were, of course, it made
sense - but it violates least surprise quite badly.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

[RFA/stabs reader] Fix v3 duplicate constructors problem

[Daniel Jacobowitz]

I tracked down the annoying duplication of constructors using G++ 3.0 with
stabs.  The problem is that all the clones of the constructor are emitted,
so there really are two of them.

The obvious thing to do to fix this in GCC (and I'd like it fixed in GCC)
would seem to be checking DECL_ABSTRACT_ORIGIN like the Dwarf frontend does
instead of DECL_ABSTRACT.  That works for eliminating the duplicates and
creating the names we need, but the mangled name in debug info is the
"*INTERNAL*" version if we do that.  I'd like to emit the name of the
constructor and the mangled name of the complete object constructor,
ideally.  C++ people, does that sound right?  Or feasible?

Unlike the vtable fixes, though, I can fix this in GDB too.  I'm planning to
do both, since GCCs with this issue have been circulating for a long time.

I'm still running tests on this, but it looks pretty good so far.  OK to
commit when they're done?

In addition, it nicely gets us:

XPASS: gdb.base/constvars.exp: ptype lecherous
XPASS: gdb.base/constvars.exp: ptype lectern

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

2001-12-03  Daniel Jacobowitz  <drow@mvista.com>

	* stabsread.c (read_member_functions): Skip member functions which
	are duplicates of the callable constructor/destructor.

Index: stabsread.c
===================================================================
RCS file: /cvs/src/src/gdb/stabsread.c,v
retrieving revision 1.16
diff -u -p -r1.16 stabsread.c
--- stabsread.c	2001/09/24 17:16:53	1.16
+++ stabsread.c	2001/12/03 20:40:11
@@ -2953,6 +2953,7 @@ read_member_functions (struct field_info
 {
   int nfn_fields = 0;
   int length = 0;
+  int skip_method;
   /* Total number of member functions defined in this class.  If the class
      defines two `f' functions, and one `g' function, then this will have
      the value 3.  */
@@ -2991,6 +2992,36 @@ read_member_functions (struct field_info
       sublist = NULL;
       look_ahead_type = NULL;
       length = 0;
+
+      skip_method = 0;
+      if (p - *pp == strlen ("__base_ctor")
+	  && strncmp (*pp, "__base_ctor", strlen ("__base_ctor")) == 0)
+	skip_method = 1;
+      else if (p - *pp == strlen ("__base_dtor")
+	       && strncmp (*pp, "__base_dtor", strlen ("__base_dtor")) == 0)
+	skip_method = 1;
+      else if (p - *pp == strlen ("__deleting_dtor")
+	       && strncmp (*pp, "__deleting_dtor",
+			   strlen ("__deleting_dtor")) == 0)
+	skip_method = 1;
+
+      if (skip_method)
+	{
+	  /* Skip past '::'.  */
+	  *pp = p + 2;
+	  /* Read the type.  */
+	  read_type (pp, objfile);
+	  /* Skip past the colon, mangled name, semicolon, flags, and final
+	     semicolon.  */
+	  while (**pp != ';')
+	    (*pp) ++;
+	  (*pp) ++;
+	  while (**pp != ';')
+	    (*pp) ++;
+	  (*pp) ++;
+
+	  continue;
+	}
 
       new_fnlist = (struct next_fnfieldlist *)
 	xmalloc (sizeof (struct next_fnfieldlist));

Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

[Daniel Berlin]

On Mon, 3 Dec 2001, Daniel Jacobowitz wrote:

> I tracked down the annoying duplication of constructors using G++ 3.0 with
> stabs.  The problem is that all the clones of the constructor are emitted,
> so there really are two of them.
>
Yes.
> The obvious thing to do to fix this in GCC (and I'd like it fixed in GCC)
> would seem to be checking DECL_ABSTRACT_ORIGIN like the Dwarf frontend does
> instead of DECL_ABSTRACT.
It *used* to do the right thing (IE after the v3 switch)
Which is to emit a single constructor name in the class, and emit the
clones outside the class debug info, with an abstract origin/specification
of the in the class die.

Does it not still do this?

Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

[Daniel Jacobowitz]

On Mon, Dec 03, 2001 at 04:22:14PM -0500, Daniel Berlin wrote:
> 
> 
> On Mon, 3 Dec 2001, Daniel Jacobowitz wrote:
> 
> > I tracked down the annoying duplication of constructors using G++ 3.0 with
> > stabs.  The problem is that all the clones of the constructor are emitted,
> > so there really are two of them.
> >
> Yes.
> > The obvious thing to do to fix this in GCC (and I'd like it fixed in GCC)
> > would seem to be checking DECL_ABSTRACT_ORIGIN like the Dwarf frontend does
> > instead of DECL_ABSTRACT.
> It *used* to do the right thing (IE after the v3 switch)
> Which is to emit a single constructor name in the class, and emit the
> clones outside the class debug info, with an abstract origin/specification
> of the in the class die.
> 
> Does it not still do this?

It does for Dwarf2.  This particular problem does not affect Dwarf2. 
Dies don't come into this anywhere.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

[Daniel Berlin]

On Mon, 3 Dec 2001, Daniel Jacobowitz wrote:

> On Mon, Dec 03, 2001 at 04:22:14PM -0500, Daniel Berlin wrote:
> >
> >
> > On Mon, 3 Dec 2001, Daniel Jacobowitz wrote:
> >
> > > I tracked down the annoying duplication of constructors using G++ 3.0 with
> > > stabs.  The problem is that all the clones of the constructor are emitted,
> > > so there really are two of them.
> > >
> > Yes.
> > > The obvious thing to do to fix this in GCC (and I'd like it fixed in GCC)
> > > would seem to be checking DECL_ABSTRACT_ORIGIN like the Dwarf frontend does
> > > instead of DECL_ABSTRACT.
> > It *used* to do the right thing (IE after the v3 switch)
> > Which is to emit a single constructor name in the class, and emit the
> > clones outside the class debug info, with an abstract origin/specification
> > of the in the class die.
> >
> > Does it not still do this?
>
> It does for Dwarf2.  This particular problem does not affect Dwarf2.
> Dies don't come into this anywhere.

Sorry, missed the part where you said it was with stabs.
--Dan

Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

[Jason Merrill]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

[redirected to gcc list, rather than libstdc++]

> I tracked down the annoying duplication of constructors using G++ 3.0 with
> stabs.  The problem is that all the clones of the constructor are emitted,
> so there really are two of them.

Yep.

> The obvious thing to do to fix this in GCC (and I'd like it fixed in GCC)
> would seem to be checking DECL_ABSTRACT_ORIGIN like the Dwarf frontend does
> instead of DECL_ABSTRACT.  That works for eliminating the duplicates and
> creating the names we need, but the mangled name in debug info is the
> "*INTERNAL*" version if we do that.  I'd like to emit the name of the
> constructor and the mangled name of the complete object constructor,
> ideally.  C++ people, does that sound right?  Or feasible?

It's certainly feasible; when we see the abstract version, look ahead for a
clone and use its mangled name.

The thing is, we want the debugger to treat them as the same function, so
that setting a breakpoint on the signature actually sets one on each and
the like.  I suppose that ideal will not be affected by your change, both
because (I assume) it doesn't work now and because we use the demangled
names for most purposes anyway.

What does GDB actually use the member function information for?  What
impact would this change have, other than the output of ptype?

Jason

Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

[Daniel Jacobowitz]

On Mon, Dec 03, 2001 at 09:49:39PM +0000, Jason Merrill wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
> [redirected to gcc list, rather than libstdc++]
> 
> > I tracked down the annoying duplication of constructors using G++ 3.0 with
> > stabs.  The problem is that all the clones of the constructor are emitted,
> > so there really are two of them.
> 
> Yep.
> 
> > The obvious thing to do to fix this in GCC (and I'd like it fixed in GCC)
> > would seem to be checking DECL_ABSTRACT_ORIGIN like the Dwarf frontend does
> > instead of DECL_ABSTRACT.  That works for eliminating the duplicates and
> > creating the names we need, but the mangled name in debug info is the
> > "*INTERNAL*" version if we do that.  I'd like to emit the name of the
> > constructor and the mangled name of the complete object constructor,
> > ideally.  C++ people, does that sound right?  Or feasible?
> 
> It's certainly feasible; when we see the abstract version, look ahead for a
> clone and use its mangled name.
> 
> The thing is, we want the debugger to treat them as the same function, so
> that setting a breakpoint on the signature actually sets one on each and
> the like.  I suppose that ideal will not be affected by your change, both
> because (I assume) it doesn't work now and because we use the demangled
> names for most purposes anyway.
> 
> What does GDB actually use the member function information for?  What
> impact would this change have, other than the output of ptype?

Right now, the big thing is probably member function calls.  If the
constructor is called from GDB, we want to get the complete object
constructor.  I'm not 100% sure this is even possible, though.

I hadn't considered setting breakpoints on all of them.  That's very
difficult; suppose I look at an assembly listing for a constructor and
tell it to break on a particular line.  How can I figure out source
line information for every constructor?  I've no idea what happens in
this case.

Perhaps it is best to continue emitting them and ignore them until we
support them in GDB.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

[Jason Merrill]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

>> What does GDB actually use the member function information for?  What
>> impact would this change have, other than the output of ptype?

> Right now, the big thing is probably member function calls.  If the
> constructor is called from GDB, we want to get the complete object
> constructor.  I'm not 100% sure this is even possible, though.

You can't call a constructor directly in C++; no reason to allow it from
GDB.  Destructors are a different matter, though; an explicit call should
go to the non-deleting, in-charge version.

> I hadn't considered setting breakpoints on all of them.  That's very
> difficult; suppose I look at an assembly listing for a constructor and
> tell it to break on a particular line.  How can I figure out source
> line information for every constructor?

With Dwarf, all clones/inlines point to the abstract version; the internal
representation could keep track of all instances of a particular abstract
function.

> Perhaps it is best to continue emitting them and ignore them until we
> support them in GDB.

Seems reasonable.

Jason

Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

[Michael Snyder]

Jason Merrill wrote:
> 
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
> >> What does GDB actually use the member function information for?  What
> >> impact would this change have, other than the output of ptype?
> 
> > Right now, the big thing is probably member function calls.  If the
> > constructor is called from GDB, we want to get the complete object
> > constructor.  I'm not 100% sure this is even possible, though.
> 
> You can't call a constructor directly in C++; no reason to allow it from
> GDB. 

OTOH, there are a lot of things that you can do from GDB
that you cannot do programmatically.  Accessing private data
would be an example.  Since GDB can call any other function, 
is there a strong reason why it should not be able to call
the constructors?  

If constructors are a special case type of function which 
GDB cannot call, we ought to document that fact.

Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

[Jason Merrill]

>>>>> "Michael" == Michael Snyder <msnyder@cygnus.com> writes:

> Jason Merrill wrote:

>> You can't call a constructor directly in C++; no reason to allow it from
>> GDB. 

> OTOH, there are a lot of things that you can do from GDB
> that you cannot do programmatically.  Accessing private data
> would be an example.  Since GDB can call any other function, 
> is there a strong reason why it should not be able to call
> the constructors?  

Constructors and destructors have traditionally had a special calling
convention.  Though I suppose that as of v3, we've gone to clones rather
than extra hidden parameters, so it would be more feasible to allow users
to call them directly from the debugger.  In any case, it needs some sort
of special handling.

Jason

Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

[Jim Blandy]

Jason Merrill <jason@redhat.com> writes:
> Constructors and destructors have traditionally had a special calling
> convention.  Though I suppose that as of v3, we've gone to clones rather
> than extra hidden parameters, so it would be more feasible to allow users
> to call them directly from the debugger.  In any case, it needs some sort
> of special handling.

Wouldn't it be reasonable for GDB to support `new' expressions?

Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

[Joe Buck]

> 
> 
> Jason Merrill <jason@redhat.com> writes:
> > Constructors and destructors have traditionally had a special calling
> > convention.  Though I suppose that as of v3, we've gone to clones rather
> > than extra hidden parameters, so it would be more feasible to allow users
> > to call them directly from the debugger.  In any case, it needs some sort
> > of special handling.
> 
> Wouldn't it be reasonable for GDB to support `new' expressions?

Yes, if the gdb user can call placement new, s/he can call a constructor
and place an object whereever desired.  Something like

(gdb) call new(ptr) SomeClass(1, "Hello")

Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> I'm still running tests on this, but it looks pretty good so far.  OK to
> commit when they're done?

Yes, please commit.

Re: [RFA/stabs reader] Fix v3 duplicate constructors problem

[Daniel Jacobowitz]

On Fri, Dec 07, 2001 at 06:26:18PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > I'm still running tests on this, but it looks pretty good so far.  OK to
> > commit when they're done?
> 
> Yes, please commit.

Thanks, committed.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer