lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 29 Nov 2017 10:14:37 +0100
From:   Thomas-Mich Richter <tmricht@...ux.vnet.ibm.com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Jiri Olsa <jolsa@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-perf-use." <linux-perf-users@...r.kernel.org>
Subject: Re: Question to perf annotate handling mov ...(%rip) instructions

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

Powered by blists - more mailing lists