public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

       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