From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Thomas-Mich Richter <tmricht@linux.vnet.ibm.com>
Cc: Jiri Olsa <jolsa@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-perf-use." <linux-perf-users@vger.kernel.org>
Subject: Re: Question to perf annotate handling mov ...(%rip) instructions
Date: Tue, 28 Nov 2017 11:50:30 -0300 [thread overview]
Message-ID: <20171128145030.GG3298@kernel.org> (raw)
In-Reply-To: <f241fe0b-7a3f-cb6a-51ee-4833bce81e70@linux.vnet.ibm.com>
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
next parent reply other threads:[~2017-11-28 14:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <f241fe0b-7a3f-cb6a-51ee-4833bce81e70@linux.vnet.ibm.com>
2017-11-28 14:50 ` Arnaldo Carvalho de Melo [this message]
2017-11-29 8:29 ` Question to perf annotate handling mov ...(%rip) instructions Jiri Olsa
2017-11-29 9:14 ` Thomas-Mich Richter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171128145030.GG3298@kernel.org \
--to=acme@kernel.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=tmricht@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox