Re: Is physname mangled or not? (PR c++/8216)

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Daniel Jacobowitz wrote:
> On Wed, May 04, 2011 at 07:32:43PM +0200, Ulrich Weigand wrote:
> > It seems that by now we have agreement that GCC is correct here.  So I guess
> > I see two options remaining:
> > 
> > - Code a test that compares class name and (demangled) function name, but
> >   explicitly removes template instance parameters first
> > 
> > or
> > 
> > - Have the symbol reader call is_constructor_name on the mangled name while
> >   it is still available, and store that information somewhere in the type
> >   information
> > 
> > Thoughts?
> 
> I'd suggest the former.  Anything you do with mangled names will be
> unexpectedly complex; sometimes you just can't count on having them.

OK, I see.  I've done a little more digging through the history, and I guess
I understand a little better why things were done the way they were.

Mostly, it seems to have come down to the problem that some past compilers
used to fill in silly things for the debug data method names of special
methods like constructors (e.g. __comp_ctor).  See the long comment in
stabsread.c:read_member_functions.

To work around this, the code tries to "re-create" the proper method name
using a variety of approaches, amongst others by looking at the physname
(which at this point is a mangled name) if present (in stabs).

Mostly, this gets done when the method definition is read in.  However, there
are cases where this is apparently not possible, and the method is marked as
a "stub".  There is a routine check_stub_method_group that users of the
method list are apparently supposed to call before looking at method names,
which "unstubs" methods and corrects all names as appropriate.  This is done
in various places (search_struct_method etc.).

However, there are other places -in particular c_type_print_base, which is
what initially started this discussion- that do *not* call the helper
check_stub_method_group to fix things up.  Instead (apparently) those places
try to handle stubbed methods directly, duplicating various parts of what
check_stub_method_group would do (e.g. call gdb_mangle_name).

*This* in turn appears to be the reason why c_type_print_base does the
weird duplicate check for constructors/destructors looking both at the
method name and the physname -- the former is needed because physname
is not always available, the latter is needed because the method name
may be wrong for stubbed methods.


So, if the analysis so far is correct, it would appear to me that the
best way forward is actually to:

- change c_type_print_base (and other places) to actually just call
  check_stub_method_group, and then assume the method name is always
  correct -- removing all the extra code required for stubbed methods,
  including the physname-based constructor/destructor checks

- update the method name based checks to handle templates.

B.t.w. at yet another location in linespec.c:find_methods, an attempt
to handle templates seems to have been made when detecting constructors:

          else if (strncmp (class_name, name, name_len) == 0
                   && (class_name[name_len] == '\0'
                       || class_name[name_len] == '<'))


Does this look reasonable?

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com