This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] handling of 'operator' in cp_find_first_component
On Mon, 21 Apr 2003 23:21:52 -0400, Daniel Jacobowitz <drow at mvista dot com> said:
> As Daniel Berlin pointed out, the demangler is behaving correctly.
> The return type is part of the mangled signature in this case, and
> must be.
I'm actually curious why it must be, but that's another issue; it
simply is the case that it's part of the mangled signature, so the
demangler is behaving correctly.
> However, for GDB's purposes, is it _necessary_ or _useful_ to have
> said mangled name? If not, for another project I already have a
> cplus_demangle wrapper which plays with the resulting names.
> Adapting it to detect and remove return types would probably be
> easy.
I suspect that it's not useful (I'll talk more about that downthread);
whether or not it's useful, I'm pretty sure that, right now, it's
actively harmful. We have code in GDB that deals with function names;
that code assumes that the function names doesn't have certain
characteristics. So if the demangler is returning "int foo<int>(int)"
then I bet that "break foo<int>" doesn't work for us.
I would be tempted to put the code to not give return types in the
demangler itself, though, rather than in a post-processor: that seems
to me to be more reliable and more efficient.
> I am not strong in this area of C++, but as far as I know this should
> suffice; the demangled name of such a function will always include the
> template parameters; and the template-id must be unique in the program
> (right? Not sure if the ODR comes into play here or not) so either
> there is only one possible return value or the template parameters
> uniquely identify the return value.
> i.e. you can't have a program with
> int foo<int> (int)
> and
> long foo<int> (int)
> in it!
That's my attitude, too. Template parameters and argument types can
distinguish functions; return types can't. At least I assume so; on
the other hand, presumably the ABI authors had a reason for including
return types in the demangled name in this situation. But even if
there are some strange boundary cases where it's necessary to
disambiguate functions, I still think that, right now, GDB is much
more likely to be hurt than to be helped by having return types in
there.
> That said, I still think your patch is OK; on the condition that it
> handles the test case the comment you're removing refers to. Something
> like:
> int foo<operator() (B&)>
> or whatever it was in the right syntax. Does it, and can you add that
> to the maint.exp tests?
It should handle them, but you're right, I should include such
examples in the maint.exp tests. I'll go off and generate some
examples first before checking it in.
David Carlton
carlton at math dot stanford dot edu