Question to perf annotate handling mov ...(%rip) instructions

Question to perf annotate handling mov ...(%rip) instructions

[Thomas-Mich Richter]

I am confused by perf annotate internals.

Perf annotate examines a perf.data file and shows disassembler output.
However the output differs depending on the output option specified:

‑‑stdio: Output to stdout, also selected implicitly when output piped to another
process or redirected to a file. The function call sequence is 

symbol__tty_annotate() –> symbol__annotate_printf() –> disasm_line__print().

This output style does not annotate the branch instructions nor does it use special 
printing functions in the util/annotate.c, for example mov__scnprintf().

‑‑tui: Default. there are annotations to augment branches, jumps, fct returns 
with arrows for interactive usage. The function call stack starts with 
symbol__tui_annotate(). 
There is also special treatment for the Intel mov instructions of the form:

00000000000060b0 <_init@@Base>: 
.... 
60b4:       48 8b 05 35 cd 22 00    mov 0x22cd35(%rip),%rax   # 232df0 <__gmon_start__>     

Commit 6de783b6f50f7f1db18a3fda0aa34b2e84b5771d ("perf annotate: Resolve symbols 
using objdump comment") added this support.

Special code for Intel platform handles the mov  at address 60b4: 
This is dynamic linkage against the PLT. Function mov__parse() is always called 
to parse the objdump comment following the '#' character. 
However the function mov__scnprintf() to replace the text '0x22cd35(%rip)' by the 
target function name __gmon_start__ is only called in tui mode and not in stdio mode.

Now to the confusion:
Function mov__parse() calls comment__symbol() which contains:

   static int comment__symbol(char *raw, char *comment, u64 *addrp, char **namep)
   {
        char *endptr, *name, *t;

        if (strstr(raw, "(%rip)") == NULL)
                return 0;

This is architecture specific and does not work for non-Intel platforms.

I would like to fix perf annotate for s390x and above move instruction on s390x
is
     
    655a:       c0 10 00 01 9c eb       larl    %r1,39f30 <__gmon_start__>

There is a need to handle PLT resolution in an architecture independent way.

Ideas and suggestions?

-- 
Thomas Richter, Dept 3303, IBM LTC Boeblingen Germany
--
Vorsitzende des Aufsichtsrats: Martina Koederitz 
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294

Re: Question to perf annotate handling mov ...(%rip) instructions

[Arnaldo Carvalho de Melo]

Em Tue, Nov 28, 2017 at 11:42:16AM +0100, Thomas-Mich Richter escreveu:
> I am confused by perf annotate internals.
> 
> Perf annotate examines a perf.data file and shows disassembler output.
> However the output differs depending on the output option specified:

Well, we started with the --stdio code, and then, for the TUI, went on
improving to be able to navigate, etc.

The --stdio code was then left for us to compare outputs and see if some
regression was being added.

I think that the right thing is to have the --stdio use what is in
--tui, modulo the interactive bits.

The --tui has knobs to disable its beautifications, see H in the tui
annotation browser to see the toggle hotkeys.
 
> ‑‑stdio: Output to stdout, also selected implicitly when output piped to another
> process or redirected to a file. The function call sequence is 
> 
> symbol__tty_annotate() –> symbol__annotate_printf() –> disasm_line__print().
> 
> This output style does not annotate the branch instructions nor does it use special 
> printing functions in the util/annotate.c, for example mov__scnprintf().
> 
> ‑‑tui: Default. there are annotations to augment branches, jumps, fct returns 
> with arrows for interactive usage. The function call stack starts with 
> symbol__tui_annotate(). 
> There is also special treatment for the Intel mov instructions of the form:

The cases where intel has special treatment are bugs, should be moved to
arch specific callbacks.
 
> 00000000000060b0 <_init@@Base>: 
> .... 
> 60b4:       48 8b 05 35 cd 22 00    mov 0x22cd35(%rip),%rax   # 232df0 <__gmon_start__>     
> 
> Commit 6de783b6f50f7f1db18a3fda0aa34b2e84b5771d ("perf annotate: Resolve symbols 
> using objdump comment") added this support.
> 
> Special code for Intel platform handles the mov  at address 60b4: 
> This is dynamic linkage against the PLT. Function mov__parse() is always called 
> to parse the objdump comment following the '#' character. 
> However the function mov__scnprintf() to replace the text '0x22cd35(%rip)' by the 
> target function name __gmon_start__ is only called in tui mode and not in stdio mode.
> 
> Now to the confusion:
> Function mov__parse() calls comment__symbol() which contains:
> 
>    static int comment__symbol(char *raw, char *comment, u64 *addrp, char **namep)
>    {
>         char *endptr, *name, *t;
> 
>         if (strstr(raw, "(%rip)") == NULL)
>                 return 0;
> 
> This is architecture specific and does not work for non-Intel platforms.
> 
> I would like to fix perf annotate for s390x and above move instruction on s390x
> is
>      
>     655a:       c0 10 00 01 9c eb       larl    %r1,39f30 <__gmon_start__>
> 
> There is a need to handle PLT resolution in an architecture independent way.
> 
> Ideas and suggestions?

Some historical background there, busy now, but you seem to be on the
right track and IIRC you already sent a patch for this, right? I'll try
to look at it.

Jiri may as well, since he worked a lot recently in this codebase, to
refactor it some more to make it useful for annotating python code, perl
next, other scripted languages should follow too.

- Arnaldo

Re: Question to perf annotate handling mov ...(%rip) instructions

[Jiri Olsa]

On Tue, Nov 28, 2017 at 11:50:30AM -0300, Arnaldo Carvalho de Melo wrote:

SNIP

> > Function mov__parse() calls comment__symbol() which contains:
> > 
> >    static int comment__symbol(char *raw, char *comment, u64 *addrp, char **namep)
> >    {
> >         char *endptr, *name, *t;
> > 
> >         if (strstr(raw, "(%rip)") == NULL)
> >                 return 0;
> > 
> > This is architecture specific and does not work for non-Intel platforms.
> > 
> > I would like to fix perf annotate for s390x and above move instruction on s390x
> > is
> >      
> >     655a:       c0 10 00 01 9c eb       larl    %r1,39f30 <__gmon_start__>
> > 
> > There is a need to handle PLT resolution in an architecture independent way.
> > 
> > Ideas and suggestions?
> 
> Some historical background there, busy now, but you seem to be on the
> right track and IIRC you already sent a patch for this, right? I'll try
> to look at it.
> 
> Jiri may as well, since he worked a lot recently in this codebase, to
> refactor it some more to make it useful for annotating python code, perl
> next, other scripted languages should follow too.

so we try to parse each line out of objdump using arch specific
ops callbacks, check:

disasm_line__new
  disasm_line__init_ins
    dl->ins.ops->parse(...

the ops stuff are defined in:

static struct arch architectures[] = { 

        {
                .name = "s390",
                .init = s390__annotate_init,
                .objdump =  {
                        .comment_char = '#',
                },
        },

I'd check s390__annotate_init, there's some mechanism
of associating ops for arch and try to fit in ;-)

jirka

Re: Question to perf annotate handling mov ...(%rip) instructions

[Thomas-Mich Richter]

On 11/28/2017 03:50 PM, Arnaldo Carvalho de Melo wrote:

.....

>> .... 
>> 60b4:       48 8b 05 35 cd 22 00    mov 0x22cd35(%rip),%rax   # 232df0 <__gmon_start__>     
>>
>> Commit 6de783b6f50f7f1db18a3fda0aa34b2e84b5771d ("perf annotate: Resolve symbols 
>> using objdump comment") added this support.
>>
>> Special code for Intel platform handles the mov  at address 60b4: 
>> This is dynamic linkage against the PLT. Function mov__parse() is always called 
>> to parse the objdump comment following the '#' character. 
>> However the function mov__scnprintf() to replace the text '0x22cd35(%rip)' by the 
>> target function name __gmon_start__ is only called in tui mode and not in stdio mode.
>>
>> Now to the confusion:
>> Function mov__parse() calls comment__symbol() which contains:
>>
>>    static int comment__symbol(char *raw, char *comment, u64 *addrp, char **namep)
>>    {
>>         char *endptr, *name, *t;
>>
>>         if (strstr(raw, "(%rip)") == NULL)
>>                 return 0;
>>
>> This is architecture specific and does not work for non-Intel platforms.
>>
>> I would like to fix perf annotate for s390x and above move instruction on s390x
>> is
>>      
>>     655a:       c0 10 00 01 9c eb       larl    %r1,39f30 <__gmon_start__>
>>
>> There is a need to handle PLT resolution in an architecture independent way.
>>
>> Ideas and suggestions?
> 
> Some historical background there, busy now, but you seem to be on the
> right track and IIRC you already sent a patch for this, right? I'll try
> to look at it.

The two patches I sent are unrelated to this issue.

> Jiri may as well, since he worked a lot recently in this codebase, to
> refactor it some more to make it useful for annotating python code, perl
> next, other scripted languages should follow too.

-- 
Thomas Richter, Dept 3303, IBM LTC Boeblingen Germany
--
Vorsitzende des Aufsichtsrats: Martina Koederitz 
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294

Re: Question to perf annotate handling mov ...(%rip) instructions

[Thomas-Mich Richter]

On 11/29/2017 09:29 AM, Jiri Olsa wrote:
> On Tue, Nov 28, 2017 at 11:50:30AM -0300, Arnaldo Carvalho de Melo wrote:
> 
> SNIP
> 
>>> Function mov__parse() calls comment__symbol() which contains:
>>>
>>>    static int comment__symbol(char *raw, char *comment, u64 *addrp, char **namep)
>>>    {
>>>         char *endptr, *name, *t;
>>>
>>>         if (strstr(raw, "(%rip)") == NULL)
>>>                 return 0;
>>>
>>> This is architecture specific and does not work for non-Intel platforms.
>>>
>>> I would like to fix perf annotate for s390x and above move instruction on s390x
>>> is
>>>      
>>>     655a:       c0 10 00 01 9c eb       larl    %r1,39f30 <__gmon_start__>
>>>
>>> There is a need to handle PLT resolution in an architecture independent way.
>>>
>>> Ideas and suggestions?
>>
>> Some historical background there, busy now, but you seem to be on the
>> right track and IIRC you already sent a patch for this, right? I'll try
>> to look at it.
>>
>> Jiri may as well, since he worked a lot recently in this codebase, to
>> refactor it some more to make it useful for annotating python code, perl
>> next, other scripted languages should follow too.
> 
> so we try to parse each line out of objdump using arch specific
> ops callbacks, check:
> 
> disasm_line__new
>   disasm_line__init_ins
>     dl->ins.ops->parse(...
> 
> the ops stuff are defined in:
> 
> static struct arch architectures[] = { 
> 
>         {
>                 .name = "s390",
>                 .init = s390__annotate_init,
>                 .objdump =  {
>                         .comment_char = '#',
>                 },
>         },
> 
> I'd check s390__annotate_init, there's some mechanism
> of associating ops for arch and try to fit in ;-)
> 
> jirka
> 

Ahhhh, I get it now. The code in util/annotate.c (for example mov__parse())
is in a common code file, but these functions are called via architecture 
depended triggers.

I'll go and try something for s390x to handle PLT resolution.

-- 
Thomas Richter, Dept 3303, IBM LTC Boeblingen Germany
--
Vorsitzende des Aufsichtsrats: Martina Koederitz 
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294