[lkml]   [2017]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Question to perf annotate handling mov ...(%rip) instructions
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 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

 \ /
  Last update: 2017-11-28 15:51    [W:0.062 / U:2.960 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site