[BUG] perf tools: Demangle kernel and kernel module symbols too

[BUG] perf tools: Demangle kernel and kernel module symbols too

[Jiri Olsa]

hi,
Jan Stancek found test 1 breakage, probably caused by following patch:
  950b8354716e perf tools: Demangle kernel and kernel module symbols too

it seems to break test 1:
---
[jolsa@krava perf]$ ./perf test -v 1
 1: vmlinux symtab matches kallsyms                        :
--- start ---
test child forked, pid 6288
Looking at the vmlinux_path (6 entries long)

SNIP

0xffffffff8142dba0: diff name v: event_queue virtual table k: __vt_event_queue
0xffffffff8142dc00: diff name v: event_dequeue virtual table k: __vt_event_dequeue
0xffffffff8142dd90: diff name v: event_wait::isra::::part:: virtual table k: __vt_event_wait.isra.0.part.1
---

Avi,
could you please update the tests/vmlinux-kallsyms.c to reflect
the demangle change?

thanks,
jirka

Re: [BUG] perf tools: Demangle kernel and kernel module symbols too

[Jiri Olsa]

ping

On Sat, Sep 06, 2014 at 08:46:31PM +0200, Jiri Olsa wrote:
> hi,
> Jan Stancek found test 1 breakage, probably caused by following patch:
>   950b8354716e perf tools: Demangle kernel and kernel module symbols too
> 
> it seems to break test 1:
> ---
> [jolsa@krava perf]$ ./perf test -v 1
>  1: vmlinux symtab matches kallsyms                        :
> --- start ---
> test child forked, pid 6288
> Looking at the vmlinux_path (6 entries long)
> 
> SNIP
> 
> 0xffffffff8142dba0: diff name v: event_queue virtual table k: __vt_event_queue
> 0xffffffff8142dc00: diff name v: event_dequeue virtual table k: __vt_event_dequeue
> 0xffffffff8142dd90: diff name v: event_wait::isra::::part:: virtual table k: __vt_event_wait.isra.0.part.1
> ---
> 
> Avi,
> could you please update the tests/vmlinux-kallsyms.c to reflect
> the demangle change?
> 
> thanks,
> jirka

Re: [BUG] perf tools: Demangle kernel and kernel module symbols too

[Avi Kivity]

On 09/06/2014 09:46 PM, Jiri Olsa wrote:
> hi,
> Jan Stancek found test 1 breakage, probably caused by following patch:
>    950b8354716e perf tools: Demangle kernel and kernel module symbols too
>
> it seems to break test 1:
> ---
> [jolsa@krava perf]$ ./perf test -v 1
>   1: vmlinux symtab matches kallsyms                        :
> --- start ---
> test child forked, pid 6288
> Looking at the vmlinux_path (6 entries long)
>
> SNIP
>
> 0xffffffff8142dba0: diff name v: event_queue virtual table k: __vt_event_queue
> 0xffffffff8142dc00: diff name v: event_dequeue virtual table k: __vt_event_dequeue
> 0xffffffff8142dd90: diff name v: event_wait::isra::::part:: virtual table k: __vt_event_wait.isra.0.part.1
> ---
>
> Avi,
> could you please update the tests/vmlinux-kallsyms.c to reflect
> the demangle change?
>
>

It's not a simple matter of updating the test: the demangler interprets 
name beginning with __vt as C++ mangles names, which of course they aren't.

The only way I see to proceed is to make the demangling optional, 
default off.

Re: [BUG] perf tools: Demangle kernel and kernel module symbols too

[Peter Zijlstra]

On Sat, Sep 13, 2014 at 06:34:37AM +0300, Avi Kivity wrote:

> It's not a simple matter of updating the test: the demangler interprets name
> beginning with __vt as C++ mangles names, which of course they aren't.

Oh, that'll give cute 'problems' in a mixed C/C++ project that just
happens to have __vt names in. Now of course I'm aware that C/C++
'reserve' the __ prefix, which I suppose that makes it less likely in
practise.

> The only way I see to proceed is to make the demangling optional, default
> off.

Seems like a good way out, we could think about adding a language
heuristic that tries and guess the target language and auto enables when
it guesses C++, but that needs to have overrides as well.

Re: [BUG] perf tools: Demangle kernel and kernel module symbols too

[Avi Kivity]

On 09/14/2014 12:41 PM, Peter Zijlstra wrote:
> On Sat, Sep 13, 2014 at 06:34:37AM +0300, Avi Kivity wrote:
>
>> It's not a simple matter of updating the test: the demangler interprets name
>> beginning with __vt as C++ mangles names, which of course they aren't.
> Oh, that'll give cute 'problems' in a mixed C/C++ project that just
> happens to have __vt names in. Now of course I'm aware that C/C++
> 'reserve' the __ prefix, which I suppose that makes it less likely in
> practise.

If you have clashes there, perf demangling is the least of your worries.

>> The only way I see to proceed is to make the demangling optional, default
>> off.
> Seems like a good way out, we could think about adding a language
> heuristic that tries and guess the target language and auto enables when
> it guesses C++, but that needs to have overrides as well.

It should be easy to look for common C++ mangled name
prefixes and use that as a guess, but I expect that users
who profile C++ guest kernels (or kernel modules) are
capable of adding the switch themselves.