C++ demangling of 64-bit symbols on ppc64

C++ demangling of 64-bit symbols on ppc64

[Maynard Johnson]

Hi all,
As the de facto maintainer of the ppc64 bits of oprofile, I was recently 
asked to look into an oprofile bug where it was incorrectly demangling 
64-bit symbols.  The oprofile code uses the libiberty function, 
cplus_demangle(), but is not getting back the right answer for ppc64 
64-bit symbols.  This appears to be more fallout from the change (made a 
couple years ago or so) to the opd for ppc64, where the leading "." was 
removed from 64-bit symbols.

I hacked around the problem in my private oprofile src tree, but I'm 
thinking this issue should be solved at its source.  I'm seeing this 
problem on a SLES 10 system with binutils version 2.16.91.  Has this 
possibly been resolved in a more recent binutils version or in CVS?

Thanks.
-Maynard

Re: C++ demangling of 64-bit symbols on ppc64

[Ian Lance Taylor]

Maynard Johnson <maynardj@us.ibm.com> writes:

> As the de facto maintainer of the ppc64 bits of oprofile, I was
> recently asked to look into an oprofile bug where it was incorrectly
> demangling 64-bit symbols.  The oprofile code uses the libiberty
> function, cplus_demangle(), but is not getting back the right answer
> for ppc64 64-bit symbols.  This appears to be more fallout from the
> change (made a couple years ago or so) to the opd for ppc64, where the
> leading "." was removed from 64-bit symbols.
> 
> I hacked around the problem in my private oprofile src tree, but I'm
> thinking this issue should be solved at its source.  I'm seeing this
> problem on a SLES 10 system with binutils version 2.16.91.  Has this
> possibly been resolved in a more recent binutils version or in CVS?

Can you give an example of a symbol which the demangler is not
handling correctly?

Ian

Re: C++ demangling of 64-bit symbols on ppc64

[Maynard Johnson]

Ian Lance Taylor wrote:

>Maynard Johnson <maynardj@us.ibm.com> writes:
>
>  
>
>>As the de facto maintainer of the ppc64 bits of oprofile, I was
>>recently asked to look into an oprofile bug where it was incorrectly
>>demangling 64-bit symbols.  The oprofile code uses the libiberty
>>function, cplus_demangle(), but is not getting back the right answer
>>for ppc64 64-bit symbols.  This appears to be more fallout from the
>>change (made a couple years ago or so) to the opd for ppc64, where the
>>leading "." was removed from 64-bit symbols.
>>
>>I hacked around the problem in my private oprofile src tree, but I'm
>>thinking this issue should be solved at its source.  I'm seeing this
>>problem on a SLES 10 system with binutils version 2.16.91.  Has this
>>possibly been resolved in a more recent binutils version or in CVS?
>>    
>>
>
>Can you give an example of a symbol which the demangler is not
>handling correctly?
>  
>
Below is the testcase provided to me by the person who reported it:

==========

void doit(char *str)
{
        while (1)
                ;
}

char *blah;
int main()
{
        doit(blah);
}

When built as 32bit:

# g++ -O2 test.c -o test

opreport -l gives:

42345    89.6627  test                     doit(char*)

However when built as 64bit:

# g++ -m64 -O2 test.c -o test

opreport -l gives:

6513     93.7392  test                     ._Z4doitPc

=================

Regards,
-Maynard

>Ian
>  
>

Re: C++ demangling of 64-bit symbols on ppc64

[Ian Lance Taylor]

Maynard Johnson <maynardj@us.ibm.com> writes:

> 6513     93.7392  test                     ._Z4doitPc

So the problem is the leading dot (which was probably clear to you but
not to me).  Historically the demangler has not handled leading dots.
Instead, historically, the caller has removed them when appropriate.

The linker, rather than do anything clever, simply removes all leading
dots.  See the demangle() function in ld/ldmisc.c.

  /* This is a hack for better error reporting on XCOFF, PowerPC64-ELF
     or the MS PE format.  These formats have a number of leading '.'s
     on at least some symbols, so we remove all dots to avoid
     confusing the demangler.  */
  p = name;
  while (*p == '.')
    ++p;

It seems to me that opreport should do the same.

Or, we could change the interface to the demangler.  I don't think it
would be appropriate for the demangler to unconditionally remove
leading dots, but I think it would be reasonable to add a DMGL_XX flag
for it if that seems like a better approach.

Ian

Re: C++ demangling of 64-bit symbols on ppc64

[Maynard Johnson]

Ian Lance Taylor wrote:

>Maynard Johnson <maynardj@us.ibm.com> writes:
>
>  
>
>>6513     93.7392  test                     ._Z4doitPc
>>    
>>
>
>So the problem is the leading dot (which was probably clear to you but
>not to me).  Historically the demangler has not handled leading dots.
>Instead, historically, the caller has removed them when appropriate.
>
>The linker, rather than do anything clever, simply removes all leading
>dots.  See the demangle() function in ld/ldmisc.c.
>
>  /* This is a hack for better error reporting on XCOFF, PowerPC64-ELF
>     or the MS PE format.  These formats have a number of leading '.'s
>     on at least some symbols, so we remove all dots to avoid
>     confusing the demangler.  */
>  p = name;
>  while (*p == '.')
>    ++p;
>
>It seems to me that opreport should do the same.
>
>Or, we could change the interface to the demangler.  I don't think it
>would be appropriate for the demangler to unconditionally remove
>  
>
Why?  Are there some circumstances where the correct answer is returned, 
even if the symbol has leading dots?

>leading dots, but I think it would be reasonable to add a DMGL_XX flag
>for it if that seems like a better approach.
>  
>
If default removal of leading dots is not possible or practical, then 
I'd agree that something like DMGL_HANDLE_LEADING_DOTS would be an OK 
approach -- in order to centralize the knowledge of what should be done 
with leading dots.  Of course, no matter what the decision, adding a 
hack (similar to above) to opreport will be necessary for now.

Thanks.
-Maynard

>Ian
>  
>

Re: C++ demangling of 64-bit symbols on ppc64

[Ian Lance Taylor]

Maynard Johnson <maynardj@us.ibm.com> writes:

> >Or, we could change the interface to the demangler.  I don't think it
> >would be appropriate for the demangler to unconditionally remove
> >
> Why?  Are there some circumstances where the correct answer is
> returned, even if the symbol has leading dots?

I believe the demangler should by default strive to avoid converting
two different mangled symbol names to the same demangled string.  When
it does so, the output of nm --demangle becomes confusing.

Ian