On 17/09/16 16:33, Masami Hiramatsu wrote:
> On Fri, 16 Sep 2016 09:32:43 -0600
> Mathieu Poirier <mathieu.poir...@linaro.org> wrote:
>> On 13 September 2016 at 17:25, Masami Hiramatsu <mhira...@kernel.org> wrote:
>>> On Tue, 13 Sep 2016 08:18:10 -0600
>>> Mathieu Poirier <mathieu.poir...@linaro.org> wrote:
>>>> On 13 September 2016 at 04:01, Adrian Hunter <adrian.hun...@intel.com>
>>>>> On 12/09/16 20:53, Mathieu Poirier wrote:
>>>>>> This patch makes it possible to use the current filter
>>>>>> framework with address filters. That way address filters for
>>>>>> HW tracers such as CoreSight and IntelPT can be communicated
>>>>>> to the kernel drivers.
>>>>>> Signed-off-by: Mathieu Poirier <mathieu.poir...@linaro.org>
>>>>>> Changes for V5:
>>>>>> - Modified perf_evsel__append_filter() to take a string format
>>>>>> rather than an operation.
>>>>> Hope I'm not being a pain, but aren't there other places calling
>>>>> perf_evsel__append_filter() that need to be changed. Might make
>>>>> sense as a separate patch.
>>>> No no, you're right - I completely overlooked that.
>>>> But shouldn't it be in the same patch? That way a git bisect would
>>>> stay consistent...
>>> You're right. Caller and callee should be changed in atomic.
>>> BTW, could you add document updates how the perf command line
>>> will be changed, and also show the result in the patch description?
>> This patch does not change anything on the perf command line. It
>> simply allows current options to succeed (as they should) rather than
> Yes, and it will make perf acceptable to pass --filter to CoreSight or
> Intel PT events, or am I misunderstand?
> If it is correct, could you give us an example how to pass it, since
> tools/perf/Documentation/perf-record.txt says it is only for tracepoints?
I am adding support for symbols in the address filter. I will send the
patches soon, but the documentation will be:
Event filter. This option should follow a event selector (-e) which
selects either tracepoint event(s) or a hardware trace PMU
(e.g. Intel PT or CoreSight).
- tracepoint filters
In the case of tracepoints, multiple '--filter' options are combined
- address filters
A hardware trace PMU advertises its ability to accept a number of
address filters by specifying a non-zero value in
Address filters have the format:
filter|start|stop|tracestop <start> [/ <size>] [@<file name>]
- 'filter': defines a region that will be traced.
- 'start': defines an address at which tracing will begin.
- 'stop': defines an address at which tracing will stop.
- 'tracestop': defines a region in which tracing will stop.
<file name> is the name of the object file, <start> is the offset to the
code to trace in that file, and <size> is the size of the region to
trace. 'start' and 'stop' filters need not specify a <size>.
If no object file is specified then the kernel is assumed, in which case
the start address must be a current kernel memory address.
<start> can also be specified by providing the name of a symbol. If the
symbol name is not unique, it can be disambiguated by inserting #n where
'n' selects the n'th symbol in address order. Alternately #0, #g or #G
select only a global symbol. <size> can also be specified by providing
the name of a symbol, in which case the size is calculated to the end
of that symbol. For 'filter' and 'tracestop' filters, if <size> is
omitted and <start> is a symbol, then the size is calculated to the end
of that symbol.
If <size> is omitted and <start> is '*', then the start and size will
be calculated from the first and last symbols, i.e. to trace the whole
If symbol names (or "*") are provided, they must be surrounded by white
The filter passed to the kernel is not necessarily the same as entered.
To see the filter that is passed, use the -v option.
The kernel may not be able to configure a trace region if it is not
within a single mapping. MMAP events (or /proc/<pid>/maps) can be
examined to determine if that is a possibility.
Multiple filters can be separated with space or comma.