linux-kernel - Re: Re: [PATCH -tip ] [BUGFIX] perf probe: Add a workaround for GCC -mfentry

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 linux-hardening linux-cve-announce 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:	Thu, 04 Oct 2012 10:55:54 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Mark Wielaard <mjw@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>
Cc:	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Ingo Molnar <mingo@...e.hu>, Michal Marek <mmarek@...e.cz>,
	Andi Kleen <andi@...stfloor.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Paul Mackerras <paulus@...ba.org>, systemtap@...rceware.org,
	yrl.pp-manager.tt@...achi.com
Subject: Re: Re: [PATCH -tip ] [BUGFIX] perf probe: Add a workaround for
 GCC -mfentry

(2012/10/04 1:00), Mark Wielaard wrote:
> On Wed, 2012-10-03 at 09:53 -0400, Steven Rostedt wrote:
>> On Wed, 2012-10-03 at 21:17 +0900, Masami Hiramatsu wrote:
>>>  <1><9a58>: Abbrev Number: 86 (DW_TAG_subprogram)
>>>     <9a59>   DW_AT_external    : 1
>>>     <9a59>   DW_AT_name        : (indirect string, offset: 0xd82): unregister_di
>>> e_notifier
>>>     <9a5d>   DW_AT_decl_file   : 1
>>>     <9a5e>   DW_AT_decl_line   : 551
>>>     <9a60>   DW_AT_prototyped  : 1
>>>     <9a60>   DW_AT_type        : <0x7c>
>>>     <9a64>   DW_AT_low_pc      : 0x740
>>>     <9a6c>   DW_AT_high_pc     : 0x75a
>>>     <9a74>   DW_AT_frame_base  : 1 byte block: 9c       (DW_OP_call_frame_cfa)
>>>     <9a76>   DW_AT_GNU_all_call_sites: 1
>>>     <9a76>   DW_AT_sibling     : <0x9aac>
>>>  <2><9a7a>: Abbrev Number: 87 (DW_TAG_formal_parameter)
>>>     <9a7b>   DW_AT_name        : nb
>>>     <9a7e>   DW_AT_decl_file   : 1
>>>     <9a7f>   DW_AT_decl_line   : 551
>>>     <9a81>   DW_AT_type        : <0x2a96>
>>>     <9a85>   DW_AT_location    : 0x172f (location list)
>>> ...
>>>     0000172f 0000000000000745 0000000000000750 (DW_OP_reg5 (rdi))
>>>     0000172f 0000000000000750 0000000000000757 (DW_OP_reg4 (rsi))
>>>     0000172f 0000000000000757 000000000000075a (DW_OP_GNU_entry_value: (DW_OP_reg5 (rdi)); DW_OP_stack_value)
>>>     0000172f <End of list>
>>> -----
>>>
>>> As you can see, the location of the parameter "nb", starts from 0x745
>>> but unregister_die_notifier() function itself starts from 0x740.
>>
>> Um, no I can't see. I guess I need to go and read up on DWARF formats.
>> Any good recommended links?
>>
>> A quick google gives me:
>>
>> http://en.wikipedia.org/wiki/DWARF
>> http://wiki.dwarfstd.org/index.php?title=Dwarf_FAQ
>> http://www.eagercon.com/dwarf/dwarf-2.0.0.pdf
>>
>> Is this what you recommend reading? Or is there better documentation?
> 
> DWARF2 is pretty old, the latest DWARF standard is
> http://www.dwarfstd.org/Dwarf4Std.php
> If you like details then you'll want to read section 2.5 DWARF
> Expressions and 2.6 Location Descriptions. (That is what the
> DW_AT_location attribute for the DW_TAG_formal_parameter points at.) You
> might also want to read a bit about some of the DWARF5/GNU extensions
> commonly used. I tried to add references to them on this page:
> https://fedorahosted.org/elfutils/wiki/DwarfExtensions
> (Look for the Expression Opcodes)
> 
> So in the above example it tries to say that for function (subprogram)
> "unregister_di_notifier" runs from (low_pc) 0x740 till (high_pc) 0x75a
> and for the parameter "nb" the value can be found in the rdi register
> from address 0x745 till 0x750, in register rsi from address 0x750 till
> 0x575 and for 0x757 till 0x75a it would be the value of register rsi as
> it was on function entry (yes, that just means it isn't available
> anymore and you need to either unwind to function start to get it or
> have it recorded on function entry to retrieve it at this point). The
> above also implies that from address 0x740 till 0x745 GCC didn't record
> the location of nb (or it just hasn't materialized yet).
> 
> Note that the GCC hackers already seem to have identified why that is in
> this case: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793#c2

Thanks for the perfect explanation!

And sorry, I should explain not why but what happened...

Without this patch, perf probe doesn't work correctly about finding
function parameters on function entries.

----
# ./perf probe -V vfs_read
Available variables at vfs_read
        @<vfs_read+0>
                (No matched variables)
----

Not only showing parameters, but also setting parameters failed.

----
# ./perf probe vfs_read buf
Failed to find the location of buf at this address.
 Perhaps, it has been optimized out.
Failed to find 'buf' in this function.
  Error: Failed to add events. (-2)
----

With this patch, perf can handle parameters again.

----
# ./perf probe -V vfs_read
Available variables at vfs_read
        @<vfs_read+0>
                char*   buf
                loff_t* pos
                size_t  count
                struct file*    file
----

and

----
# ./perf probe vfs_read buf
Added new event:
  probe:vfs_read       (on vfs_read with buf)

You can now use it in all perf tools, such as:

        perf record -e probe:vfs_read -aR sleep 1
----

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/