The operation '%' is not implemented on event-parse.c, causing an error
when parsing events with '%' the operation in its printk format. For
example,

  # perf record -e sched:sched_deadline_yield ~/yield-test
    Warning: [sched:sched_deadline_yield] unknown op '%'
  ....
  # perf script
    Warning: [sched:sched_deadline_yield] unknown op '%'
        test  1641 [006]  3364.109319: sched:sched_deadline_yield: \
                        [FAILED TO PARSE] now=3364109314595        \
                        deadline=3364139295135 runtime=19975597

This patch implements the '%' operation. With this patch, we see the
correct output:

  # perf record -e sched:sched_deadline_yield ~/yield-test
    No Warning

  # perf script
        yield-test  4005 [001]  4623.650978: sched:sched_deadline_yield: \
                now=4623.650974050                                       \
                deadline=4623.680957364 remaining_runtime=19979611
Signed-off-by: NDaniel Bristot de Oliveira <bristot@redhat.com>
Reviewed-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Juri Lelli <juri.lelli@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-rt-users <linux-rt-users@vger.kernel.org>
Link: http://lkml.kernel.org/r/5c96a395c56cea6d3d13d949051bdece86cc26e0.1456157869.git.bristot@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

The print_event_field() and print_event_fields() functions print basic
information of a given field or event without the print format.  They'll
be used by dynamic sort keys later.

Committer note:

Rename it to pevent_print_field[s]() to get proper namespacing, as
discussed with Steven Rostedt.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Acked-by: NJiri Olsa <jolsa@kernel.org>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/1450876121-22494-1-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

The new name is irq_poll as iopoll is already taken.  Better suggestions
welcome.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NBart Van Assche <bart.vanassche@sandisk.com>

When a long value is read on 32 bit machines for 64 bit output, the
parsing needs to change "%lu" into "%llu", as the value is read
natively.

Unfortunately, if "%llu" is already there, the code will add another "l"
to it and fail to parse it properly.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20151116172516.4b79b109@gandalf.local.homeSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Commits such as 65dd297a ("xfs: %pF is only for function
pointers") caused a regression because pretty_print() didn't support
%ps/%pS.  The current %pf/%pF implementation in pretty_print() is what
%ps/%pS is supposed to do, so use the same code for %ps/%pS.

Addressing the incorrect %pf/%pF implementation is beyond the scope of
this patch.
Signed-off-by: NScott Wood <scottwood@freescale.com>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Dave Chinner <david@fromorbit.com>
Link: http://lkml.kernel.org/r/20150831211637.GA12848@home.buserror.netSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

When a trace recorded on a 32-bit device is processed with a 64-bit
binary, the higher 32-bits of the address need to ignored.

The lack of this results in the output of the 64-bit pointer
value to the trace as the 32-bit address lookup fails in find_printk().

Before:

  burn-1778  [003]   548.600305: bputs:   0xc0046db2s: 2cec5c058d98c

After:

  burn-1778  [003]   548.600305: bputs:   0xc0046db2s: RT throttling activated

The problem occurs in PRINT_FIELD when the field is recognized as a
pointer to a string (of the type const char *)

Heterogeneous architectures cases below can arise and should be handled:

* Traces recorded using 32-bit addresses processed on a 64-bit machine
* Traces recorded using 64-bit addresses processed on a 32-bit machine
Reported-by: NJuri Lelli <juri.lelli@arm.com>
Signed-off-by: NKapileshwar Singh <kapileshwar.singh@arm.com>
Reviewed-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Javi Merino <javi.merino@arm.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1442928123-13824-1-git-send-email-kapileshwar.singh@arm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Support helper function __get_dynamic_array_len() in libtraceevent, this
function is used accompany with __print_array() or __print_hex(), but
currently it is not an available function in the function list of
process_function().

The total allocated length of the dynamic array is embedded in the top
half of __data_loc_##item field. This patch adds new arg type
PRINT_DYNAMIC_ARRAY_LEN to return the length to eval_num_arg(),
Signed-off-by: NHe Kuang <hekuang@huawei.com>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1440822125-52691-32-git-send-email-wangnan0@huawei.comSigned-off-by: NWang Nan <wangnan0@huawei.com>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

It was reported that "%-8s" does not parse well when used in the printk
format. The '-' is what is throwing it off. Allow that to be included.

Reporter note:

Example before:

  transhuge-stres-10730 [004]  5897.713989: mm_compaction_finished: node=0
  zone=>-<8s order=-2119871790 ret=

Example after:

  transhuge-stres-4235  [000]   453.149280: mm_compaction_finished: node=0
  zone=ffffffff81815d7a order=9 ret=

(I will send patches to fix the string handling in the tracepoints so
it's on par with in-kernel printing via trace_pipe:)

  transhuge-stres-10921 [007] ...1  6307.140205: mm_compaction_finished: node=0
  zone=Normal   order=9 ret=partial
Reported-by: NVlastimil Babka <vbabka@suse.cz>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Tested-by: NVlastimil Babka <vbabka@suse.cz>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20150827094601.46518bcc@gandalf.local.homeSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Running the following perf-stat command on an arm64 system produces the
following result...

  [root@aarch64 ~]# perf stat -e kmem:mm_page_alloc -a sleep 1
    Warning: [kmem:mm_page_alloc] function sizeof not defined
    Warning: Error: expected type 4 but read 0
  Segmentation fault
  [root@aarch64 ~]#

The second warning was a result of the first warning not stopping
processing after it detected the issue.

That is, code that found the issue reported the first problem, but
because it did not exit out of the functions smoothly, it caused the
other warning to appear and not only that, it later caused the SIGSEGV.
Signed-off-by: NDean Nelson <dnelson@redhat.com>
Reviewed-by: NSteven Rostedt <rostedt@goodmis.org>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20150820151632.13927.13791.email-sent-by-dnelson@tealSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

The perf tools have a symbol resolver that includes solving kernel
symbols using either kallsyms or ELF symtabs, and it also is using
libtraceevent to format the trace events fields, including via
subsystem specific plugins, like the "timer" one.

To solve fields like "timer:hrtimer_start"'s "function", libtraceevent
needs a way to map from its value to a function name and addr.

This patch provides a way for tools that already have symbol resolving
facilities to ask libtraceevent to use it when needing to resolve
kernel symbols.
Reviewed-by: NSteven Rostedt <rostedt@goodmis.org>
Acked-by: NDavid Ahern <dsahern@gmail.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-fdx1fazols17w5py26ia3bwh@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Introduce an 'alias' field to 'struct format_field' to be able
to use alternative name for the field.

It is initialized with same string pointer as 'name' field.
The free logic checks the 'alias' pointer being reset by user
and frees it.

This will be handy when converting data into CTF, where each
field within event needs to have a unique name (while this
is not required for tracepoint). Converter can easily assign
unique name into the format_field struct.
Suggested-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jeremie Galarneau <jgalar@efficios.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Tom Zanussi <tzanussi@gmail.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-qwyq8blnfkg6s5vlbrvn1en3@git.kernel.org
Link: http://lkml.kernel.org/r/1429372220-6406-6-git-send-email-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

In my i386 build, it failed like this:

    CC       event-parse.o
  event-parse.c: In function 'print_str_arg':
  event-parse.c:3868:5: warning: format '%lu' expects argument of type 'long unsigned int',
                        but argument 3 has type 'uint64_t' [-Wformat]
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Acked-by: NJavi Merino <javi.merino@arm.com>
Link: http://lkml.kernel.org/r/20150424020218.GF1905@sejongSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Currently it ignores operator priority and just sets processed args as a
right operand.  But it could result in priority inversion in case that
the right operand is also a operator arg and its priority is lower.

For example, following print format is from new kmem events.

  "page=%p", REC->pfn != -1UL ? (((struct page *)(0xffffea0000000000UL)) + (REC->pfn)) : ((void *)0)

But this was treated as below:

  REC->pfn != ((null - 1UL) ? ((struct page *)0xffffea0000000000UL + REC->pfn) : (void *) 0)

In this case, the right arg was '?' operator which has lower priority.
But it just sets the whole arg so making the output confusing - page was
always 0 or 1 since that's the result of logical operation.

With this patch, it can handle it properly like following:

  ((REC->pfn != (null - 1UL)) ? ((struct page *)0xffffea0000000000UL + REC->pfn) : (void *) 0)
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Joonsoo Kim <js1304@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1428298576-9785-10-git-send-email-namhyung@kernel.org
[ Replaced 'swap' with 'rotate' in a comment as requested by Steve and agreed by Namhyung ]
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Guilherme Cox found that:

 There is, however, a potential bug if there is an item with code zero
 that is not the first one in the symbol list, since eval_flag(..)
 returns 0 when it doesn't find anything.

That is, if you have the following enums:

enum {
  FOO_START = 0,
  FOO_GO    = 1,
  FOO_END   = 2
}

and then have:

  __print_symbolic(foo, FOO_GO, "go", FOO_START, "start",
		        FOO_END, "end")

If none of the enums are known to pevent, then eval_flag() will return
zero, and it will match it to the first item in the list, which would be
FOO_GO, which is not zero.

Luckily, in most cases, the first element would be zero, and the parsing
would match out of sheer luck.
Reported-by: NGuilherme Cox <cox@computer.org>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20150324145813.0bfe95ba@gandalf.local.homeSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Use %pS for actual addresses, otherwise you'll get bad output
on arches like ppc64 where %pF expects a function descriptor.

Link: http://lkml.kernel.org/r/1426130037-17956-22-git-send-email-scottwood@freescale.comSigned-off-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>

Since 6ea22486 ("tracing: Add array printing helper") trace can
generate traces with variable element size arrays.  Add support to
parse them.
Signed-off-by: NJavi Merino <javi.merino@arm.com>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1427195239-15730-1-git-send-email-javi.merino@arm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

There is a pevent_data_comm_from_pid() that returns the cmdline stored for
a given pid in order for users to map pids to comms, but there's no method
to convert a comm back to a pid. This is useful for filters that specify
a comm instead of a PID (it's faster than searching each individual event).

Add a way to retrieve a comm from a pid. Since there can be more than one
pid associated to a comm, it returns a data structure that lets the user
iterate over all the saved comms for a given pid.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20150324135923.001103479@goodmis.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

The %z printf specifier was not handled making trace_printk()s in the
kernel that used this break on output.
Reported-by: NShawn Bohrer <shawn.bohrer@gmail.com>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Shawn Bohrer <shawn.bohrer@gmail.com>
Link: http://lkml.kernel.org/r/20150324135922.844361717@goodmis.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

The pevent->trace_clock should not be a direct pointer to what was
given. It should be copied and freed.

Note, valgrind pointed this out when a caller passed in a pointer that
needed to be freed and it never was. Ideally, pevent should copy it
(which this change does), and free the copy. It's up to the caller to
free the clock string passed in.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20150324135922.695906738@goodmis.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

It is possible that a pid has no associated comm attached to it, although it
can still be passed to pevent_register_comm().

But if comm is NULL, it will cause strdup() to segfault. To prevent this
from happening, if comm is NULL use the default "<...>" name for the
pid.
Signed-off-by: NJosef Bacik <jbacik@fb.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20150324135922.549965495@goodmis.org
Link: http://lkml.kernel.org/p/1403799732-30308-1-git-send-email-jbacik@fb.comSigned-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

The sequence of allocating the print_arg field, calling process_arg()
and verifying that the next event delimiter is repeated twice in
process_hex() and will also be used for process_int_array().

Factor it out to a function to avoid writing the same code again and
again.
Signed-off-by: NJavi Merino <javi.merino@arm.com>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1426875176-30244-2-git-send-email-javi.merino@arm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Move the calls that frees the resources allocated for a struct format_field to
a separate routine.
Signed-off-by: NDavid Ahern <dsahern@gmail.com>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/1426790181-19118-1-git-send-email-dsahern@gmail.com
[ Split this part from a larger patch, added pevent_ prefix as requested by Steven ]
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Add helpers for the following kernel formats:
  %pi4 print an IPv4 address with leading zeros
  %pI4 print an IPv4 address without leading zeros
  %pi6 print an IPv6 address without colons
  %pI6 print an IPv6 address with colons
  %pI6c print an IPv6 address in compressed form with colons
  %pISpc print an IP address from a sockaddr

Allows these formats to be used in tracepoints.

Quite a bit of this is adapted from code in lib/vsprintf.c.

v4:
- fixed pI6c description in git commit message per Valdis' comment

v3:
- use of 'c' and 'p' requires 'I'

v2:
- pass ptr+1 to print_ip_arg per Namhyung's comments
- added field length checks to sockaddr function
Signed-off-by: NDavid Ahern <dsahern@gmail.com>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1418955071-36241-1-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Fix a risk of doing free on an uninitialized pointer.

This was found using a static code analysis program called cppcheck.
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Link: http://lkml.kernel.org/r/1403608150-13037-1-git-send-email-rickard_strandqvist@spectrumdigital.seSigned-off-by: NJiri Olsa <jolsa@kernel.org>

Coming in v3.16, trace events will be able to save bitmasks in raw
format in the ring buffer and output it with the __get_bitmask() macro.

In order for userspace tools to parse this, it must be able to handle
the __get_bitmask() call and be able to convert the data that's in
the ring buffer into a nice bitmask format. The output is similar to
what the kernel uses to print bitmasks, with a comma separator every
4 bytes (8 characters).

This allows for cpumasks to also be saved efficiently.

The first user is the thermal:thermal_power_limit event which has the
following output:

 thermal_power_limit:  cpus=0000000f freq=1900000 cdev_state=0 power=5252

Link: http://lkml.kernel.org/r/20140506132238.22e136d1@gandalf.local.homeSuggested-by: NJavi Merino <javi.merino@arm.com>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Tested-by: NJavi Merino <javi.merino@arm.com>
Link: http://lkml.kernel.org/r/20140603032224.229186537@goodmis.orgSigned-off-by: NJiri Olsa <jolsa@kernel.org>

Commit 12e55569 "tools lib traceevent: Use helper trace-seq in print
functions like kernel does" added a extra trace_seq helper to process
string arguments like the kernel does it. But the difference between the
kernel and the userspace library is that the kernel's trace_seq structure
has a static allocated buffer. The userspace one has a dynamically
allocated one. It requires a trace_seq_destroy(), otherwise it produces
a nasty memory leak.

Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/20140422192330.6bb09bf8@gandalf.local.homeSigned-off-by: NJiri Olsa <jolsa@redhat.com>

The patch 3a3ffa2e ("tools lib traceevent: Report better error
message on bad function args") added the error message but it seems
there's no reason to call warning() directly.

So change it to do_warning_event() to provide event information too.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/1395192174-26273-2-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NJiri Olsa <jolsa@redhat.com>

It's sometimes useful to know where the parse failure was occurred.  Add
do_warning_event() macro to see the failing event.

It now shows the messages like below:

  $ perf test 5
   5: parse events tests                                     :  Warning: [kvmmmu:kvm_mmu_get_page] bad op token {
    Warning: [kvmmmu:kvm_mmu_sync_page] bad op token {
    Warning: [kvmmmu:kvm_mmu_unsync_page] bad op token {
    Warning: [kvmmmu:kvm_mmu_prepare_zap_page] bad op token {
    Warning: [kvmmmu:fast_page_fault] function is_writable_pte not defined
    Warning: [xen:xen_mmu_ptep_modify_prot_commit] function sizeof not defined
    Warning: [xen:xen_mmu_ptep_modify_prot_start] function sizeof not defined
    Warning: [xen:xen_mmu_set_pgd] function sizeof not defined
    Warning: [xen:xen_mmu_set_pud] function sizeof not defined
    Warning: [xen:xen_mmu_set_pmd] function sizeof not defined
    ...
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/1395192174-26273-1-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NJiri Olsa <jolsa@redhat.com>

When a plugin unloaded it needs to unregister its print handler from
pevent.

So add an unregister function to do it.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Reviewed-by: NJiri Olsa <jolsa@redhat.com>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/1389839478-5887-3-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

When a plugin is unloaded it needs to unregister its handler from pevent.

So add an unregister function to do it.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Reviewed-by: NJiri Olsa <jolsa@redhat.com>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/1389839478-5887-2-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

The pevent_filter_strerror() function is for receiving actual error
message from pevent_errno value.  To do that, add a static buffer to
event_filter for saving internal error message

If a failed function saved other information in the static buffer
returns the information, otherwise returns generic error message.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/1386833777-3790-15-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

When Jiri Olsa was writing a function callback for
scsi_trace_parse_cdb(), he thought that the traceevent library had a
bug in it because he was getting this error:

  Error: expected ')' but read ','
  Error: expected ')' but read ','
  Error: expected ')' but read ','
  Error: expected ')' but read ','

But in truth, he didn't have the write number of arguments for the
function callback, and the error was the library detecting the
discrepancy. A better error message would have prevented the confusion:

  Error: function 'scsi_trace_parse_cdb()' only expects 2 arguments but event scsi_dispatch_cmd_timeout has more
  Error: function 'scsi_trace_parse_cdb()' only expects 2 arguments but event scsi_dispatch_cmd_start has more
  Error: function 'scsi_trace_parse_cdb()' only expects 2 arguments but event scsi_dispatch_cmd_error has more
  Error: function 'scsi_trace_parse_cdb()' only expects 2 arguments but event scsi_dispatch_cmd_done has more

Or

  Error: function 'scsi_trace_parse_cdb()' expects 4 arguments but event scsi_dispatch_cmd_timeout only uses 3
  Error: function 'scsi_trace_parse_cdb()' expects 4 arguments but event scsi_dispatch_cmd_start only uses 3
  Error: function 'scsi_trace_parse_cdb()' expects 4 arguments but event scsi_dispatch_cmd_error only uses 3
  Error: function 'scsi_trace_parse_cdb()' expects 4 arguments but event scsi_dispatch_cmd_done only uses 3
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/n/tip-a4c34w62vl0diitvxb7bt3er@git.kernel.orgSigned-off-by: NJiri Olsa <jolsa@redhat.com>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Changing the pevent_parse_format interface to include the pevent handle.

The goal is to always use pevent object when dealing with traceevent
library. The reason is that we might need additional processing (like
plugins), which is not possible otherwise.

Patches follow to make this happen completely.
Signed-off-by: NJiri Olsa <jolsa@redhat.com>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/1386076182-14484-6-git-send-email-jolsa@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Jiri Olsa reported that his plugin for scsi was chopping off part of the
output. Investigating this, I found that Jiri used the same functions as
what is in the kernel, which adds the following:

	trace_seq_putc(p, 0);

This adds a '\0' to the output string. The reason this works in the
kernel is that the "p" that is passed to the function helper is a
temporary trace_seq. But in the libtraceevent library, it's the pointer
to the trace_seq used to output. By adding the '\0', it truncates the
line and nothing added after that will be printed.

We can solve this in two ways. One is to have the helper functions for
the library not add the unnecessary '\0'. The other is to change the
library to also use a helper trace_seq structure that gets copied to the
main trace_seq just like the kernel does.

The latter allows the helper functions in the plugins to be the same as
the kernel, which is the better solution.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Reported-by: NJiri Olsa <jolsa@redhat.com>
Tested-by: NJiri Olsa <jolsa@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20131119182937.401668e3@gandalf.local.homeSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

gcc complaint on 32-bit system:

  /home/acme/git/linux/tools/lib/traceevent/event-parse.c: In function ‘eval_num_arg’:
  /home/acme/git/linux/tools/lib/traceevent/event-parse.c:3468:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]

This is because the eval_num_arg returns everything as an 'unsigned long long',
so it converts a void pointer to a wider integer, fix it by converting the void
pointer to an integer of the same size, 'unsigned long', before casting it to
'unsigned long long'.
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-yllx4aqcg06v5n4vjpwiiuld@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Jiri Olsa reported that the scsi_dispatch_cmd_done event failed to parse
with:

  Error: expected type 5 but read 4
  Error: expected type 5 but read 4

The problem is with this part of the print_fmt:

  __print_symbolic(((REC->result) >> 24) & 0xff, ...

The __print_symbolic() helper function's first parameter is the field to
use to determine what symbol to print based on the value of the result.
The parser can handle one operation, but it can not handle multiple
operations ('>>' and '&').

Add code to process all operations for the field argument for
__print_symbolic() as well as __print_flags().
Reported-by: NJiri Olsa <jolsa@redhat.com>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20131118142314.27ca334b@gandalf.local.homeSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Jiri Olsa was writing a plugin for the cfg80211_tx_mlme_mgmt trace
event, and was not able to get the implemented function working.
The event's print fmt looks like:

   "netdev:%s(%d), ftype:0x%.2x", REC->name, REC->ifindex,
            __le16_to_cpup((__le16 *)__get_dynamic_array(frame))

As there's no helper function for __le16_to_cpup(), Jiri was creating one
with a plugin. But unfortunately, it would not work even though he set
up the plugin correctly.

The problem is that the function parameters do not handle the helper
function "__get_dynamic_array()", and that passes in a NULL pointer.

Adding PRINT_DYNAMIC_ARRAY direct support to eval_num_arg() allows the
use of __get_dynamic_array() in function parameters.
Reported-by: NJiri Olsa <jolsa@redhat.com>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Tested-by: NJiri Olsa <jolsa@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20131111160810.0ba9df7d@gandalf.local.homeSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Add the pevent_print_func_field() that will look up a field that is
expected to be a function pointer, and it will print the function name
and offset of the address given by the field.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20131101215501.869542711@goodmis.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Add the flags EVENT_FL_NOHANDLE and EVENT_FL_PRINTRAW to the event flags
to have the event either ignore the register handler or to ignore the
handler and also print the raw format respectively.

This allows a tool to force a raw format or non handle for an event.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20131101215501.655258742@goodmis.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Currently when using the raw format for fields, when looking at a
character array, to determine if it is a string or not, we make sure all
characters are "isprint()". If not, then we consider it a numeric array,
and print the hex numbers of the characters instead.

But it seems that '\n' fails the isprint() check! Add isspace() to the
check as well, such that if all characters pass isprint() or isspace()
it will assume the character array is a string.
Reported-by: NXenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Xenia Ragiadakou <burzalodowa@gmail.com>
Link: http://lkml.kernel.org/r/20131101215501.465091682@goodmis.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>