This patch introduces a --map-anon-mem argument to perf report to deal
with anon-executable-memory symbol parsing.
Sometimes, we mmap() executable memory area, and copy some '.so' or '.o'
files to the area, and then do the relocation and code fixing to make the
code work well. However, perf could not parse symbol info in those files,
since the memory area is not file-backended.
The problem was first discussed in :
https://lkml.org/lkml/2015/4/1/203
In this discussion, we finally preferred to something like 'perf inject'
to inject fake mmap events into perf.data. However, for embeded system
whose space is limited, it's not so wise to make another big perf.data
by 'perf inject'. So we still adopt the previous solution: introduce
'--map-anon-mem' argument and let user directly hint perf-report about
the private mapping info.
The content of this patch:
1) A new field mapping_strlist is introduced to struct report, in order
to store --map-anon-mem string for afterwards parsing.
2) A new field maps_anon is introduced to struct map_groups. maps_anon is used
to store the maps user defines directly for anon-mapping. when searching maps
in map_groups, we prefer to the maps stored in maps_anon.
3) The main part of this patch resides in builtin-report.c and session.c.
the part in builtin-report.c is charge of storing --map-anon-mem string,
while the part in session.c parses the string, create maps, and store maps
in map_groups->maps_anon.
Here is an example:
$ perf report --map-anon-mem=./libtesta.o@257,0x7f864c0000,0x60,0 \
--map-anon-mem=./libtestb.o@257,0x7f864c0060,0x1000,0
Where 257 is the pid and 0x76864c0000 is private map area got through:
mmap(NULL, 4096 * 4, PROT_EXEC|PROT_WRITE|PROT_READ, MAP_ANONYMOUS|MAP_PRIVATE, \
-1, 0);
and libtesta.o is copied to [0x7f864c0000,0x7f864c0060),
libtestb.o is copied to [0x7f864c0060,0x7f864c1060).
Signed-off-by: Wang Nan <[email protected]>
Signed-off-by: Hou Pengyang <[email protected]>
---
tools/perf/Documentation/perf-report.txt | 8 +++
tools/perf/builtin-report.c | 39 +++++++++++
tools/perf/util/map.c | 3 +-
tools/perf/util/map.h | 10 ++-
tools/perf/util/session.c | 117 +++++++++++++++++++++++++++++++
tools/perf/util/session.h | 4 ++
6 files changed, 178 insertions(+), 3 deletions(-)
diff --git a/tools/perf/Documentation/perf-report.txt b/tools/perf/Documentation/perf-report.txt
index c33b69f..78df4eb 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -353,6 +353,15 @@ OPTIONS
To disable decoding entirely, use --no-itrace.
+--map-anon-mem=objfile@pid,start,length[,pgoff]::
+ Give memory layout hints for specific process. This makes
+ perf regard provided range of memory as mapped from provided
+ file instead of its original attributes found in perf.data.
+ pid is necessary, since mmap address is meaningless for other process.
+ start and length represent the address range. pgoff represent mapping
+ offset of that file, default value is 0 (map from start of the file).
+ pid should be decimal, while for start, length, and pgoff, both
+ decimal and hexadecimal are avaliable.
include::callchain-overhead-calculation.txt[]
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 32626ea..5b6ea06 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -62,6 +62,7 @@ struct report {
u64 nr_entries;
u64 queue_size;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
+ struct strlist *mapping_strlist;
};
static int report__config(const char *var, const char *value, void *cb)
@@ -586,6 +587,32 @@ parse_percent_limit(const struct option *opt, const char *str,
return 0;
}
+static int
+append_to_strlist(const struct option *opt, const char *str,
+ int unset __maybe_unused)
+{
+ struct strlist **pslist = (struct strlist **)opt->value;
+ struct strlist *s;
+ int err;
+
+ if (!str)
+ return -1;
+
+ if (!*pslist)
+ *pslist = strlist__new(true, NULL);
+
+ s = *pslist;
+
+ if (!s) {
+ pr_err("No enough memory: can't alloc strlist\n");
+ return -ENOMEM;
+ }
+
+ err = strlist__add(s, str);
+ return err;
+}
+
+
int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused)
{
struct perf_session *session;
@@ -728,6 +755,10 @@ int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused)
OPT_CALLBACK_OPTARG(0, "itrace", &itrace_synth_opts, NULL, "opts",
"Instruction Tracing options",
itrace_parse_synth_opts),
+ OPT_CALLBACK_OPTARG(0, "map-anon-mem", &report.mapping_strlist, NULL,
+ "objfile@pid,start,length[,offset]",
+ "Provide map adjustment hinting",
+ append_to_strlist),
OPT_END()
};
struct perf_data_file file = {
@@ -767,6 +798,14 @@ repeat:
if (session == NULL)
return -1;
+ if (perf_session__map_anon(session,
+ report.mapping_strlist)) {
+ parse_options_usage(report_usage, options,
+ "map-anon-mem", 0);
+ goto error;
+ }
+
+
if (report.queue_size) {
ordered_events__set_alloc_size(&session->ordered_events,
report.queue_size);
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 1241ab9..3118ad9 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -448,6 +448,7 @@ void map_groups__init(struct map_groups *mg, struct machine *machine)
for (i = 0; i < MAP__NR_TYPES; ++i) {
maps__init(&mg->maps[i]);
}
+ maps__init(&mg->maps_anon);
mg->machine = machine;
atomic_set(&mg->refcnt, 1);
}
@@ -662,7 +663,7 @@ size_t map_groups__fprintf(struct map_groups *mg, FILE *fp)
return printed + map_groups__fprintf_removed_maps(mg, fp);
}
-static int maps__fixup_overlappings(struct maps *maps, struct map *map, FILE *fp)
+int maps__fixup_overlappings(struct maps *maps, struct map *map, FILE *fp)
{
struct rb_root *root;
struct rb_node *next;
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index b8df09d..d804910 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -67,6 +67,7 @@ struct maps {
};
struct map_groups {
+ struct maps maps_anon;
struct maps maps[MAP__NR_TYPES];
struct machine *machine;
atomic_t refcnt;
@@ -183,6 +184,8 @@ void maps__insert(struct maps *maps, struct map *map);
void maps__remove(struct maps *maps, struct map *map);
struct map *maps__find(struct maps *maps, u64 addr);
struct map *maps__first(struct maps *maps);
+int maps__fixup_overlappings(struct maps *maps, struct map *map, FILE *fp);
+
struct map *map__next(struct map *map);
void map_groups__init(struct map_groups *mg, struct machine *machine);
void map_groups__exit(struct map_groups *mg);
@@ -207,7 +210,11 @@ static inline void map_groups__remove(struct map_groups *mg, struct map *map)
static inline struct map *map_groups__find(struct map_groups *mg,
enum map_type type, u64 addr)
{
- return maps__find(&mg->maps[type], addr);
+ struct map *map = NULL;
+
+ if (type == MAP__FUNCTION)
+ map = maps__find(&mg->maps_anon, addr);
+ return map ? map : maps__find(&mg->maps[type], addr);
}
static inline struct map *map_groups__first(struct map_groups *mg,
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index f31e024..3e3a7e5 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1999,3 +1999,120 @@ out_err:
return err;
}
+
+static int
+parse_map_anon_mem(const char *str, char *path,
+ int *p_pid, u64 *p_addr, u64 *p_length,
+ u64 *p_offset)
+{
+ char *sep, *pos;
+ int path_sz;
+
+ path[0] = '\0';
+ *p_pid = -1;
+ *p_addr = *p_length = *p_offset = 0;
+
+ sep = strchr(str, '@');
+ if (!sep)
+ return -1;
+
+ path_sz = sep - str;
+ strncpy(path, str, path_sz >= PATH_MAX ? PATH_MAX : path_sz);
+ path[PATH_MAX - 1] = '\0';
+ if (path_sz < PATH_MAX)
+ path[path_sz] = '\0';
+
+ /* skip '@' */
+ pos = sep + 1;
+ if (*pos == '\0')
+ return -1;
+
+ *p_pid = strtol(pos, &sep, 10);
+ if (*sep != ',')
+ return -1;
+
+ pos = sep + 1;
+ if (!strncmp(pos,"0x",2) || !strncmp(pos,"0X",2))
+ *p_addr = strtoll(pos, &sep, 16);
+ else
+ *p_addr = strtoll(pos, &sep, 10);
+ if (*sep != ',')
+ return -1;
+
+ pos = sep + 1;
+ if (!strncmp(pos,"0x",2) || !strncmp(pos,"0X",2))
+ *p_length = strtoll(pos, &sep, 16);
+ else
+ *p_length = strtoll(pos, &sep, 10);
+ if (*sep == '\0')
+ return 0;
+ if (*sep != ',')
+ return -1;
+
+ pos = sep + 1;
+ if (!strncmp(pos,"0x",2) || !strncmp(pos,"0X",2))
+ *p_offset = strtoll(pos, &sep, 16);
+ else
+ *p_offset = strtoll(pos, &sep, 10);
+ if (*sep != '\0')
+ return -1;
+ return 0;
+}
+
+static int
+__perf_session__map_anon(struct perf_session *session, int pid,
+ char *path, u64 addr, u64 length,
+ u64 offset)
+{
+ struct thread *thread;
+ struct map *map;
+ int err = -1;
+
+ thread = perf_session__findnew(session, pid);
+ if (!thread)
+ return -1;
+
+ map = map__new(&session->machines.host, addr, length, offset,
+ pid, 0, 0, 0, 0, PROT_READ | PROT_EXEC, 0, path,
+ MAP__FUNCTION, thread);
+ if (!map)
+ goto out;
+
+ maps__fixup_overlappings(&thread->mg->maps_anon, map, stderr);
+ maps__insert(&thread->mg->maps_anon, map);
+ map->groups = thread->mg;
+
+ err = 0;
+out:
+ thread__put(thread);
+ return err;
+}
+
+int perf_session__map_anon(struct perf_session *session,
+ struct strlist *slist)
+{
+ struct str_node *node;
+ int err;
+
+ if (!slist)
+ return 0;
+
+ strlist__for_each(node, slist) {
+ int pid;
+ u64 addr, length, offset;
+ const char *map_anon_cmd = node->s;
+ char path[PATH_MAX];
+
+ if (parse_map_anon_mem(map_anon_cmd, path,
+ &pid, &addr, &length, &offset))
+ return -1;
+
+ err = __perf_session__map_anon(session,
+ pid, path, addr,
+ length, offset);
+ if (err)
+ return -1;
+ }
+
+ return 0;
+}
diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
index b44afc7..8df4632 100644
--- a/tools/perf/util/session.h
+++ b/tools/perf/util/session.h
@@ -9,6 +9,7 @@
#include "thread.h"
#include "data.h"
#include "ordered-events.h"
+#include "strlist.h"
#include <linux/rbtree.h>
#include <linux/perf_event.h>
@@ -101,6 +102,9 @@ size_t perf_session__fprintf_nr_events(struct perf_session *session, FILE *fp);
struct perf_evsel *perf_session__find_first_evtype(struct perf_session *session,
unsigned int type);
+int perf_session__map_anon(struct perf_session *session,
+ struct strlist *slist);
+
void perf_evsel__print_ip(struct perf_evsel *evsel, struct perf_sample *sample,
struct addr_location *al,
unsigned int print_opts, unsigned int stack_depth);
--
1.8.5.2
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.
>
> Sometimes, we mmap() executable memory area, and copy some '.so' or '.o'
> files to the area, and then do the relocation and code fixing to make the
> code work well. However, perf could not parse symbol info in those files,
> since the memory area is not file-backended.
>
> The problem was first discussed in :
> https://lkml.org/lkml/2015/4/1/203
>
> In this discussion, we finally preferred to something like 'perf inject'
> to inject fake mmap events into perf.data. However, for embeded system
> whose space is limited, it's not so wise to make another big perf.data
> by 'perf inject'. So we still adopt the previous solution: introduce
> '--map-anon-mem' argument and let user directly hint perf-report about
> the private mapping info.
>
> The content of this patch:
> 1) A new field mapping_strlist is introduced to struct report, in order
> to store --map-anon-mem string for afterwards parsing.
> 2) A new field maps_anon is introduced to struct map_groups. maps_anon is used
> to store the maps user defines directly for anon-mapping. when searching maps
> in map_groups, we prefer to the maps stored in maps_anon.
> 3) The main part of this patch resides in builtin-report.c and session.c.
> the part in builtin-report.c is charge of storing --map-anon-mem string,
> while the part in session.c parses the string, create maps, and store maps
> in map_groups->maps_anon.
>
> Here is an example:
> $ perf report --map-anon-mem=./libtesta.o@257,0x7f864c0000,0x60,0 \
> --map-anon-mem=./libtestb.o@257,0x7f864c0060,0x1000,0
>
> Where 257 is the pid and 0x76864c0000 is private map area got through:
>
> mmap(NULL, 4096 * 4, PROT_EXEC|PROT_WRITE|PROT_READ, MAP_ANONYMOUS|MAP_PRIVATE, \
> -1, 0);
>
> and libtesta.o is copied to [0x7f864c0000,0x7f864c0060),
> libtestb.o is copied to [0x7f864c0060,0x7f864c1060).
Please describe how we implement it briefly.
> Signed-off-by: Wang Nan <[email protected]>
> Signed-off-by: Hou Pengyang <[email protected]>
> ---
> tools/perf/Documentation/perf-report.txt | 8 +++
> tools/perf/builtin-report.c | 39 +++++++++++
> tools/perf/util/map.c | 3 +-
> tools/perf/util/map.h | 10 ++-
> tools/perf/util/session.c | 117 +++++++++++++++++++++++++++++++
> tools/perf/util/session.h | 4 ++
> 6 files changed, 178 insertions(+), 3 deletions(-)
>
[SNIP]
> +
> int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused)
> {
> struct perf_session *session;
> @@ -728,6 +755,10 @@ int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused)
> OPT_CALLBACK_OPTARG(0, "itrace", &itrace_synth_opts, NULL, "opts",
> "Instruction Tracing options",
> itrace_parse_synth_opts),
> + OPT_CALLBACK_OPTARG(0, "map-anon-mem", &report.mapping_strlist, NULL,
> + "objfile@pid,start,length[,offset]",
> + "Provide map adjustment hinting",
> + append_to_strlist),
> OPT_END()
> };
> struct perf_data_file file = {
> @@ -767,6 +798,14 @@ repeat:
> if (session == NULL)
> return -1;
>
> + if (perf_session__map_anon(session,
> + report.mapping_strlist)) {
> + parse_options_usage(report_usage, options,
> + "map-anon-mem", 0);
> + goto error;
> + }
> +
> +
> if (report.queue_size) {
> ordered_events__set_alloc_size(&session->ordered_events,
> report.queue_size);
>
[SNIP]
> +static int
> +__perf_session__map_anon(struct perf_session *session, int pid,
> + char *path, u64 addr, u64 length,
> + u64 offset)
> +{
> + struct thread *thread;
> + struct map *map;
> + int err = -1;
> +
> + thread = perf_session__findnew(session, pid);
> + if (!thread)
> + return -1;
Here is a problem: if there is a FORK event in perf.data for that thread,
the thread created here will be cleared, the user defined mapping is also
removed.
> +
> + map = map__new(&session->machines.host, addr, length, offset,
> + pid, 0, 0, 0, 0, PROT_READ | PROT_EXEC, 0, path,
> + MAP__FUNCTION, thread);
> + if (!map)
> + goto out;
> +
> + maps__fixup_overlappings(&thread->mg->maps_anon, map, stderr);
> + maps__insert(&thread->mg->maps_anon, map);
> + map->groups = thread->mg;
> +
> + err = 0;
> +out:
> + thread__put(thread);
> + return err;
> +}
> +
> +int perf_session__map_anon(struct perf_session *session,
> + struct strlist *slist)
> +{
> + struct str_node *node;
> + int err;
> +
> + if (!slist)
> + return 0;
> +
> + strlist__for_each(node, slist) {
> + int pid;
> + u64 addr, length, offset;
> + const char *map_anon_cmd = node->s;
> + char path[PATH_MAX];
> +
> + if (parse_map_anon_mem(map_anon_cmd, path,
> + &pid, &addr, &length, &offset))
> + return -1;
> +
> + err = __perf_session__map_anon(session,
> + pid, path, addr,
> + length, offset);
> + if (err)
> + return -1;
> + }
> +
> + return 0;
> +}
>
[SNIP]
I think splitting this patch into small pieces can make it easier to read:
perf tools: map: Search user defined map area list before areas get from
perf.data
perf tools: Creat user defined map area list when creating 'struct thread'
perf record: Introduce --custom-map options
Thank you.
* Wangnan (F) <[email protected]> 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?
The user should not be required to know about such details!
Thanks,
Ingo
Em Fri, Jun 19, 2015 at 12:42:14PM +0200, Ingo Molnar escreveu:
> * Wangnan (F) <[email protected]> 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?
>
> The user should not be required to know about such details!
Also I think we shouldn't have two maps instances, i.e. if one wants to
insert some "map files", i.e. details about a map on a file, csv or any
other format (JSON anyone? :-)), or like he did, on the command line,
then it should be added to the existing per thread tree of maps, i.e.
would be useful for some super specialized corner case but wouldn't
impact the common case, i.e. no try this tree of maps, if it is not
there, then try the other, that everybody else uses, etc.
- Arnaldo
On 2015/6/19 18:42, Ingo Molnar wrote:
>
> * Wangnan (F) <[email protected]> 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.
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
Em Mon, Jun 22, 2015 at 11:22:13PM +0800, Hou Pengyang escreveu:
> On 2015/6/19 18:42, Ingo Molnar wrote:
> >
> >* Wangnan (F) <[email protected]> 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 [email protected]
> >More majordomo info at http://vger.kernel.org/majordomo-info.html
> >Please read the FAQ at http://www.tux.org/lkml/
> >
> >
>