From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Hou Pengyang <houpengyang@huawei.com>
Cc: Ingo Molnar <mingo@kernel.org>,
"Wangnan (F)" <wangnan0@huawei.com>,
mingo@redhat.com, namhyung@kernel.org, a.p.zijlstra@chello.nl,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] perf report: introduce --map-anon-mem for anon-executable-memory symbols parsing
Date: Mon, 22 Jun 2015 12:53:49 -0300 [thread overview]
Message-ID: <20150622155349.GG13937@kernel.org> (raw)
In-Reply-To: <55882825.3030804@huawei.com>
Em Mon, Jun 22, 2015 at 11:22:13PM +0800, Hou Pengyang escreveu:
> On 2015/6/19 18:42, Ingo Molnar wrote:
> >
> >* Wangnan (F) <wangnan0@huawei.com> wrote:
> >
> >>On 2015/6/18 22:01, Hou Pengyang wrote:
> >>>This patch introduces a --map-anon-mem argument to perf report to deal
> >>>with anon-executable-memory symbol parsing.
> >>
> >>--map-anon-mem is not a good name. The user defined map area list
> >>introduced in this patch can be used on not only anon mapping but
> >>also file mapping.
> >
> >Yeah, so quirky options generally suck and only 0.01% of the users will use it.
> >It's in a way worse than not having this code, because we'll have to maintain it,
> >but it won't be used.
> >
> >Is there a way to auto-detect 'executable anon mappings' (perhaps by generating an
> >MMAP event with some extra bit set, or a new MMAP event?) so that it's all
> >seemless?
> >
> I think it not difficult to generate such MMAP event, just like :
>
> 0 435090424309600 0x3e0 [0x68]: PERF_RECORD_MMAP2
> 788/788:[0x7f946c0000(0x4000) @ 0x7f946c0000 00:00 0 0]: ---p //anon
>
> But for symbol parsing, this is not enough. For such mmap area, perf
> doesn't know the path of '.so/.o', which is necessarcy for symbol-
> parsing. So we need to tell perf the relationship between the .so file and
> the mmap range explicitly.
What is done to provide maps for JIT is detailed at:
tools/perf/Documentation/jit-interface.txt
Are you sure that can't be used for you guys? Its already automagically
done, you just have to provide a file for that pid with the mappings.
Sure, it is not for ELF, but that could be easily done, just autodetect
the map type.
- Arnaldo
> Thanks,
> Hou
>
> >The user should not be required to know about such details!
> >
> >Thanks,
> >
> > Ingo
> >--
> >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at http://vger.kernel.org/majordomo-info.html
> >Please read the FAQ at http://www.tux.org/lkml/
> >
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
prev parent reply other threads:[~2015-06-22 15:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 14:01 [RFC] perf report: introduce --map-anon-mem for anon-executable-memory symbols parsing Hou Pengyang
2015-06-19 9:27 ` Wangnan (F)
2015-06-19 10:42 ` Ingo Molnar
2015-06-19 20:10 ` Arnaldo Carvalho de Melo
2015-06-22 15:22 ` Hou Pengyang
2015-06-22 15:53 ` Arnaldo Carvalho de Melo [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=20150622155349.GG13937@kernel.org \
--to=acme@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=houpengyang@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=wangnan0@huawei.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.