From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Mark Wielaard <mjw@redhat.com>, Steven Rostedt <rostedt@goodmis.org>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>,
Ingo Molnar <mingo@elte.hu>, Michal Marek <mmarek@suse.cz>,
Andi Kleen <andi@firstfloor.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Paul Mackerras <paulus@samba.org>,
systemtap@sourceware.org, yrl.pp-manager.tt@hitachi.com
Subject: Re: Re: [PATCH -tip ] [BUGFIX] perf probe: Add a workaround for GCC -mfentry
Date: Thu, 04 Oct 2012 10:55:54 +0900 [thread overview]
Message-ID: <506CECAA.6080205@hitachi.com> (raw)
In-Reply-To: <1349280029.2682.221.camel@springer.wildebeest.org>
(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@hitachi.com
prev parent reply other threads:[~2012-10-04 1:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-03 12:17 [PATCH -tip ] [BUGFIX] perf probe: Add a workaround for GCC -mfentry Masami Hiramatsu
2012-10-03 12:27 ` Andi Kleen
2012-10-03 13:12 ` Masami Hiramatsu
2012-10-03 13:53 ` Steven Rostedt
2012-10-03 16:00 ` Mark Wielaard
2012-10-04 1:55 ` Masami Hiramatsu [this message]
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=506CECAA.6080205@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@infradead.org \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=mjw@redhat.com \
--cc=mmarek@suse.cz \
--cc=paulus@samba.org \
--cc=rostedt@goodmis.org \
--cc=systemtap@sourceware.org \
--cc=yrl.pp-manager.tt@hitachi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.