On Mon, 19 Sep 2016 09:15:40 +0300 Adrian Hunter <adrian.hun...@intel.com> wrote:
> 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> > >>>> wrote: > >>>>> 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 > >> fail. > > > > 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: > > --filter=<filter>:: > 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 > using '&&'. > > - address filters > > A hardware trace PMU advertises its ability to accept a number of > address filters by specifying a non-zero value in > /sys/bus/event_source/devices/<pmu>/nr_addr_filters. > > Address filters have the format: > > filter|start|stop|tracestop <start> [/ <size>] [@<file name>] > > Where: > - '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 > file. > > If symbol names (or "*") are provided, they must be surrounded by white > space. > > 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. Perfect! :) OK, I'll wait your patch. Thank you, -- Masami Hiramatsu <mhira...@kernel.org>
