* C++ demangling of 64-bit symbols on ppc64
@ 2007-04-03 22:19 Maynard Johnson
2007-04-05 1:04 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Maynard Johnson @ 2007-04-03 22:19 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: C++ demangling of 64-bit symbols on ppc64
2007-04-03 22:19 C++ demangling of 64-bit symbols on ppc64 Maynard Johnson
@ 2007-04-05 1:04 ` Ian Lance Taylor
2007-04-05 13:10 ` Maynard Johnson
0 siblings, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 2007-04-05 1:04 UTC (permalink / raw)
To: maynardj; +Cc: binutils
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: C++ demangling of 64-bit symbols on ppc64
2007-04-05 1:04 ` Ian Lance Taylor
@ 2007-04-05 13:10 ` Maynard Johnson
2007-04-05 16:00 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Maynard Johnson @ 2007-04-05 13:10 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: binutils
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
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: C++ demangling of 64-bit symbols on ppc64
2007-04-05 13:10 ` Maynard Johnson
@ 2007-04-05 16:00 ` Ian Lance Taylor
2007-04-05 19:16 ` Maynard Johnson
0 siblings, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 2007-04-05 16:00 UTC (permalink / raw)
To: Maynard Johnson; +Cc: binutils
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: C++ demangling of 64-bit symbols on ppc64
2007-04-05 16:00 ` Ian Lance Taylor
@ 2007-04-05 19:16 ` Maynard Johnson
2007-04-06 0:55 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Maynard Johnson @ 2007-04-05 19:16 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: binutils
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
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: C++ demangling of 64-bit symbols on ppc64
2007-04-05 19:16 ` Maynard Johnson
@ 2007-04-06 0:55 ` Ian Lance Taylor
0 siblings, 0 replies; 6+ messages in thread
From: Ian Lance Taylor @ 2007-04-06 0:55 UTC (permalink / raw)
To: Maynard Johnson; +Cc: binutils
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-04-06 0:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-04-03 22:19 C++ demangling of 64-bit symbols on ppc64 Maynard Johnson
2007-04-05 1:04 ` Ian Lance Taylor
2007-04-05 13:10 ` Maynard Johnson
2007-04-05 16:00 ` Ian Lance Taylor
2007-04-05 19:16 ` Maynard Johnson
2007-04-06 0:55 ` Ian Lance Taylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).