lkml.org 
[lkml]   [2015]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/4] perf tools: report: introduce --map-adjustment argument.
On 2015/4/1 21:21, Jiri Olsa wrote:
> On Wed, Apr 01, 2015 at 10:33:14AM +0000, Wang Nan wrote:
>> This patch introduces a --map-adjustment argument for perf report. The
>> goal of this option is to deal with private dynamic loader used in some
>> special program.
>>
>
> SNIP
>
>> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
>> index 051883a..dc9e91e 100644
>> --- a/tools/perf/util/machine.c
>> +++ b/tools/perf/util/machine.c
>> @@ -1155,21 +1155,291 @@ out_problem:
>> return -1;
>> }
>>
>> +/*
>> + * Users are allowed to provide map adjustment setting for the case
>> + * that an address range is actually privatly mapped but known to be
>> + * ELF object file backended. Like this:
>> + *
>> + * |<- copied from libx.so ->| |<- copied from liby.so ->|
>> + * |<-------------------- MMAP area --------------------->|
>> + *
>> + * When dealing with such mmap events, try to obey user adjustment.
>> + * Such adjustment settings are not allowed overlapping.
>> + * Adjustments won't be considered as valid code until real MMAP events
>> + * take place. Therefore, users are allowed to provide adjustments which
>> + * cover never mapped areas, like:
>> + *
>> + * |<- libx.so ->| |<- liby.so ->|
>> + * |<-- MMAP area -->|
>> + *
>> + * This feature is useful when dealing with private dynamic linkers,
>> + * which assemble code piece from different ELF objects.
>> + *
>> + * map_adj_list is an ordered linked list. Order of two adjustments is
>> + * first defined by their pid, and then by their start address.
>> + * Therefore, adjustments for specific pids are groupped together
>> + * naturally.
>> + */
>> +static LIST_HEAD(map_adj_list);
>
> we dont like global stuff ;-)
>
> I think this belongs to the machine object, which is created
> within the perf_session__new, so after options parsing.. hum
>

Do you think such struct map_adj objects should better reside in thread
objects?

SNIP

>
> just curious.. how many --map-adjust entries do you normaly use?
> maybe if it's bigger number then a) using rb_tree might be faster
> and b) using some sort of config file could be better way for
> input might be easier
>

The address and pid are dynamically allocated so I don't think static config
file is a good way for input. I'll consider rb_tree in my next post.

Thank you.



\
 
 \ /
  Last update: 2015-04-02 03:21    [W:0.091 / U:4.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site