Re: [PATCHv2 9/9] perf tools: Unwind properly location after REJECT

[Jiri Olsa <jolsa@redhat.com>]

On Tue, Oct 24, 2017 at 02:51:21PM +0200, Jiri Olsa wrote:
> On Fri, Oct 13, 2017 at 04:50:36PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Oct 13, 2017 at 10:37:36AM +0200, Jiri Olsa escreveu:
> > > We have defined YY_USER_ACTION to keep trace of the column
> > > location during events parsing, but we need to clean it up
> > > when we call REJECT.
> > > 
> > > When REJECT is called, the lexer shrinks the text and re-runs
> > > the matching, so we need to address it in resuming the previous
> > > location value.
> > 
> > What is this fixing? Please state that, below I show what it is breaking
> > :-/
> > 
> > Before:
> > 
> > [root@jouet ~]# perf trace --no-syscalls -e ~acme/bpf/sys_read.c/max-stack=5/ sleep 1
> > bpf: builtin compilation failed: -95, try external compiler
> >      0.000 perf_bpf_probe:func:(ffffffffbb2634e0))
> >                                        sys_read ([kernel.kallsyms])
> >                                        entry_SYSCALL_64_fastpath ([kernel.kallsyms])
> >                                        __read (/usr/lib64/ld-2.25.so)
> >                                        _dl_map_object (/usr/lib64/ld-2.25.so)
> > 
> > After:
> > 
> > [root@jouet ~]# perf trace --no-syscalls -e ~acme/bpf/sys_read.c/max-stack=5/ sleep 1
> > event syntax error: '/home/acme/bpf/sys_read.c/max-stack=5/'
> >                      \___ parser error
> > Run 'perf list' for a list of valid events
> > 
> >  Usage: perf trace [<options>] [<command>]
> >     or: perf trace [<options>] -- <command> [<options>]
> >     or: perf trace record [<options>] [<command>]
> >     or: perf trace record [<options>] -- <command> [<options>]
> > 
> >     -e, --event <event>   event/syscall selector. use 'perf list' to list available events
> > [root@jouet ~]# 
> > 
> 
> v2 with updated changelog attached,
> 
> also I rebased the rest of the fixes and pushed
> them into perf/fixes branch

and I just rebased/pushed that once again.. we are too fast ;-)

thanks,
jirka