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

[Daniel Jacobowitz <drow@mvista.com>]

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