Re: [RFA] Select a particular mangling of a demangled symbol in lookup_block_symbol

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Feb 15, 2002 at 06:38:37PM -0600, Michael Elizabeth Chastain wrote:
> Hi Daniel,
> 
> > What we really SHOULD do is set it on both constructors silently, without
> > even acknowledging that they are different functions, or else offer the user
> > the choice.  My preference is actually for the former.
> 
> There's more grossness than that.  Suppose that the constructor calls
> another function foo().  Suppose the user sets a breakpoint on foo()
> and looks at the stack and sees the constructor.  Suppose the user looks
> at the assembly code for the constructor.  Suppose the user continues,
> and takes the breakpoint on foo() again, and disassembles the constructor
> again, and sees different assembly code for the constructor.
> 
> Games like that impair the user's trust in gdb.  They start with a lie,
> And they lead to endless scenarios where you have to fix things up in
> order to maintain the lie.
> 
> I would prefer that the different blocks of object code with different
> mangled names have different demangled names as well, such as "Foo::Foo()"
> and "Foo::Foo$nic()".  (I guess if the user actually names one of his
> member functions Foo$nic then we are screwed ... is there any possible
> name which is not legal C++ member name?)

We -could- just use the names the C++ demangler provides with
DMGL_VERBOSE for some printing.  However, we want to be careful about
that.  They look like:
	A::A[not-in-charge](int).
and for max confusion:
	A::~A [not-in-charge](int)
[I should report that, I suppose...]

I would prefer to recognize this using our constructor machinery and
describe this as something like:
	A::A(int) [not-in-charge]
which is more aesthetic and lets us have a better conception of what is
going on.  Bear in mind that sometimes we look up "A::A" wanting to get
that.  Our overload handling needs some work, which I'm trying to
figure out right now.

Meanwhile, I'd like to put this patch in because it is a strict
improvement over what we have.

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