From: Masami Hiramatsu <mhiramat@kernel.org>
To: Daniel Shaulov <daniel.shaulov@gmail.com>
Cc: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
Daniel Shaulov <daniel.shaulov@granulate.io>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Thomas Richter <tmricht@linux.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf probe: Add support for DW_OP_call_frame_cfa vars
Date: Fri, 3 Apr 2020 14:39:56 +0900 [thread overview]
Message-ID: <20200403143956.f6d4f7771a55e8fe97afacee@kernel.org> (raw)
In-Reply-To: <20200402202523.GA55594@5f9ad775e7f6>
Hi Daniel,
On Thu, 2 Apr 2020 20:25:24 +0000
Daniel Shaulov <daniel.shaulov@gmail.com> wrote:
> On Thu, Apr 02, 2020 at 03:49:43PM -0300, Arnaldo Carvalho de Melo wrote:
> > Daniel, next time please consider providing precise steps to show what
> > wasn't working and then how the patch solves the problem, i.e. get some
> > go program, show the command lines used to build, probe, etc.
> >
> > - Arnaldo
>
> Sure thing:
>
> ---- contents of example.go ----
> package main
>
> import "fmt"
>
> func example(param1 int, param2 int) {
> fmt.Println(param1, param2)
> }
>
> func main() {
> example(111, 222)
> }
> ---- end contents of example.go ----
>
> Build with:
> $ go build example.go
>
> Note that the output file is named after the directory.
>
> Then try to probe it with:
> $ perf probe -x ./example 'main.example param1 param2'
>
> The result is:
> > Target program is compiled without optimization. Skipping prologue.
> > Probe on address 0x4820f0 to force probing at the function entry.
> >
> > Sorry, we don't support this variable location yet.
> > Error: Failed to add events.
>
> With my changes the event is added successfuly.
> The reason for the change can be observed in the output of:
> $ readelf --debug-dump=info ./example
>
> Where we have the following for the main.example function (with go >= 1.10):
> <1><63dd2>: Abbrev Number: 2 (DW_TAG_subprogram)
> <63dd3> DW_AT_name : main.example
> <63de0> DW_AT_low_pc : 0x4820f0
> <63de8> DW_AT_high_pc : 0x4821c2
> <63df0> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
> <63df2> DW_AT_decl_file : 0x1
> <63df6> DW_AT_external : 1
> <2><63df7>: Abbrev Number: 14 (DW_TAG_formal_parameter)
> <63df8> DW_AT_name : param1
> <63dff> DW_AT_variable_parameter: 0
> <63e00> DW_AT_decl_line : 5
> <63e01> DW_AT_type : <0x220f>
> <63e05> DW_AT_location : 1 byte block: 9c (DW_OP_call_frame_cfa)
> <2><63e07>: Abbrev Number: 14 (DW_TAG_formal_parameter)
> <63e08> DW_AT_name : param2
> <63e0f> DW_AT_variable_parameter: 0
> <63e10> DW_AT_decl_line : 5
> <63e11> DW_AT_type : <0x220f>
> <63e15> DW_AT_location : 2 byte block: 91 8 (DW_OP_fbreg: 8)
> <2><63e18>: Abbrev Number: 0
>
> The go compiler (after 1.10) uses DW_OP_call_frame_cfa for the first parameter and DW_OP_fbreg for the rest.
> On go versions lower than 1.10, it used DW_OP_call_frame_cfa for all parameters.
> Here is example output of the readelf on main.example, compiled with go1.9.7:
> <1><2634d>: Abbrev Number: 2 (DW_TAG_subprogram)
> <2634e> DW_AT_name : main.example
> <2635b> DW_AT_low_pc : 0x487db0
> <26363> DW_AT_high_pc : 0x487e99
> <2636b> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
> <2636d> DW_AT_external : 1
> <2><2636e>: Abbrev Number: 5 (DW_TAG_formal_parameter)
> <2636f> DW_AT_name : param1
> <26376> DW_AT_location : 1 byte block: 9c (DW_OP_call_frame_cfa)
> <26378> DW_AT_type : <0x27f1c>
> <2><2637c>: Abbrev Number: 5 (DW_TAG_formal_parameter)
> <2637d> DW_AT_name : param2
> <26384> DW_AT_location : 4 byte block: 9c 11 8 22 (DW_OP_call_frame_cfa; DW_OP_consts: 8; DW_OP_plus)
> <26389> DW_AT_type : <0x27f1c>
> <2><2638d>: Abbrev Number: 0
>
> Hope this makes things easier to understand.
Thanks for the explanation. That is a useful info to understand what go compiler does on dwarf.
OK, so that is same as "DW_OP_fbreg: 0".
Thank you,
>
> Daniel.
>
--
Masami Hiramatsu <mhiramat@kernel.org>
next prev parent reply other threads:[~2020-04-03 5:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-01 16:19 Daniel Shaulov
2020-04-02 18:49 ` Arnaldo Carvalho de Melo
2020-04-02 20:25 ` Daniel Shaulov
2020-04-03 5:39 ` Masami Hiramatsu [this message]
2020-04-03 13:02 ` Arnaldo Carvalho de Melo
2020-04-03 17:59 ` Daniel Shaulov
2020-04-03 5:43 ` Masami Hiramatsu
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=20200403143956.f6d4f7771a55e8fe97afacee@kernel.org \
--to=mhiramat@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=arnaldo.melo@gmail.com \
--cc=daniel.shaulov@gmail.com \
--cc=daniel.shaulov@granulate.io \
--cc=gregkh@linuxfoundation.org \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tmricht@linux.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
Powered by JetHome