From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
Ingo Molnar <mingo@kernel.org>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
David Ahern <dsahern@gmail.com>,
lkml <linux-kernel@vger.kernel.org>,
"Steven Rostedt (Red Hat)" <rostedt@goodmis.org>,
Oleg Nesterov <oleg@redhat.com>,
"David A. Long" <dave.long@linaro.org>,
systemtap@sourceware.org, yrl.pp-manager.tt@hitachi.com
Subject: Re: [PATCH -tip 3/3] perf-probe: Use the actual address as a hint for uprobes
Date: Tue, 24 Dec 2013 17:27:45 +0900 [thread overview]
Message-ID: <52B94581.40704@hitachi.com> (raw)
In-Reply-To: <87y53afzv3.fsf@sejong.aot.lge.com>
(2013/12/24 16:54), Namhyung Kim wrote:
> Hi Masami,
>
> On Mon, 23 Dec 2013 19:50:10 +0900, Masami Hiramatsu wrote:
>> (2013/12/23 16:46), Namhyung Kim wrote:
>>> On Mon, 23 Dec 2013 06:54:38 +0900, Masami Hiramatsu wrote:
>>>> (2013/12/21 3:03), Arnaldo Carvalho de Melo wrote:
>>>>> Em Fri, Dec 20, 2013 at 10:03:02AM +0000, Masami Hiramatsu escreveu:
>>>> BTW, I'm not sure why debuginfo and nm shows symbol address + 0x400000,
>>>> and why the perf's map/symbol can remove this offset. Could you tell me
>>>> how it works?
>>>> If I can get the offset (0x400000) from binary, I don't need this kind
>>>> of ugly hacks...
>>>
>>> AFAIK the actual symbol address is what nm (and debuginfo) shows. But
>>> perf adjusts symbol address to have a relative address from the start of
>>> mapping (i.e. file offset) like below:
>>>
>>> sym.st_value -= shdr.sh_addr - shdr.sh_offset;
>>
>> Thanks! this is what I really need!
BTW, what I've found is that the perf's map has start, end and pgoffs
but those are not initialized when we load user-binary (see dso__load_sym).
I'm not sure why.
>>> This way, we can handle mmap and symbol address almost uniformly
>>> (i.e. ip = map->start + symbol->address). But this requires the mmap
>>> event during perf record. For perf probe, we might need to synthesize
>>> mapping info from the section/segment header since it doesn't have the
>>> mmap event. Currently, the dso__new_map() just creates a map starts
>>> from 0.
>>
>> I think the uprobe requires only the relative address, doesn't that?
>
> Yes, but fetching arguments is little different than a normal relative
> address, I think.
Is this for uprobe probing address? or fetching symbol(global variables)?
I'd like to support uprobes probing address first.
> An offset of an argument bases on the mapping address of text segment.
> This fits naturally for a shared library case - base address is 0. So
> we can use the symbol address (st_value) directly. But for executables,
> the base address of text segment is 0x400000 on x86-64 and data symbol
> is on 0x6XXXXX typically. So in this case the offset given to uprobe
> should be "@+0x2XXXXX" (st_value - text_base).
Oh, I see. I'd better make a testcase for checking what the best
way to get such offsets.
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
next prev parent reply other threads:[~2013-12-24 8:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-20 10:02 [PATCH -tip 0/3] perf-probe: Dwarf support for uprobes Masami Hiramatsu
2013-12-20 10:02 ` [PATCH -tip 1/3] [CLEANUP] perf-probe: Expand given path to absolute path Masami Hiramatsu
2013-12-20 18:00 ` Arnaldo Carvalho de Melo
2013-12-22 21:35 ` Masami Hiramatsu
2013-12-23 14:28 ` Arnaldo Carvalho de Melo
2013-12-24 6:51 ` Masami Hiramatsu
2013-12-23 6:17 ` Namhyung Kim
2013-12-23 10:46 ` Masami Hiramatsu
2013-12-20 10:02 ` [PATCH -tip 2/3] perf-probe: Support dwarf on uprobe events Masami Hiramatsu
2013-12-20 18:01 ` Arnaldo Carvalho de Melo
2013-12-22 21:39 ` Masami Hiramatsu
2013-12-23 14:34 ` Arnaldo Carvalho de Melo
2013-12-24 1:03 ` Masami Hiramatsu
2013-12-20 10:03 ` [PATCH -tip 3/3] perf-probe: Use the actual address as a hint for uprobes Masami Hiramatsu
2013-12-20 18:03 ` Arnaldo Carvalho de Melo
2013-12-22 21:54 ` Masami Hiramatsu
2013-12-23 7:46 ` Namhyung Kim
2013-12-23 10:50 ` Masami Hiramatsu
2013-12-24 7:54 ` Namhyung Kim
2013-12-24 8:27 ` Masami Hiramatsu [this message]
2013-12-24 8:46 ` Namhyung Kim
2013-12-24 15:03 ` 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=52B94581.40704@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=acme@ghostprotocols.net \
--cc=dave.long@linaro.org \
--cc=dsahern@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=oleg@redhat.com \
--cc=rostedt@goodmis.org \
--cc=srikar@linux.vnet.ibm.com \
--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.