In order to make libtraceevent into a proper library, variables, data
structures and functions require a unique prefix to prevent name space
conflicts. That prefix will be "tep_" and not "pevent_". This changes
APIs: pevent_read_number, pevent_read_number_field
Signed-off-by: NTzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Yordan Karadzhov (VMware) <y.karadz@gmail.com>
Cc: linux-trace-devel@vger.kernel.org
Link: http://lkml.kernel.org/r/20180808180700.804271434@goodmis.orgSigned-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

In order to make libtraceevent into a proper library, variables, data
structures and functions require a unique prefix to prevent name space
conflicts. That prefix will be "tep_" and not "pevent_". This changes
APIs: pevent_print_field, pevent_print_fields, pevent_print_funcs,
pevent_print_printk
Signed-off-by: NTzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Yordan Karadzhov (VMware) <y.karadz@gmail.com>
Cc: linux-trace-devel@vger.kernel.org
Link: http://lkml.kernel.org/r/20180808180700.654453763@goodmis.orgSigned-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

In order to make libtraceevent into a proper library, variables, data
structures and functions require a unique prefix to prevent name space
conflicts. That prefix will be "tep_" and not "pevent_". This changes
APIs: pevent_parse_event, pevent_parse_format, pevent_parse_header_page
Signed-off-by: NTzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Yordan Karadzhov (VMware) <y.karadz@gmail.com>
Cc: linux-trace-devel@vger.kernel.org
Link: http://lkml.kernel.org/r/20180808180700.469749700@goodmis.orgSigned-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

In order to make libtraceevent into a proper library, variables, data
structures and functions require a unique prefix to prevent name space
conflicts. That prefix will be "tep_" and not "pevent_". This changes
APIs: pevent_find_any_field, pevent_find_common_field,
pevent_find_event, pevent_find_field
Signed-off-by: NTzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Yordan Karadzhov (VMware) <y.karadz@gmail.com>
Cc: linux-trace-devel@vger.kernel.org
Link: http://lkml.kernel.org/r/20180808180700.316995920@goodmis.orgSigned-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

In order to make libtraceevent into a proper library, variables, data
structures and functions require a unique prefix to prevent name space
conflicts. That prefix will be "tep_" and not "pevent_". This changes
APIs: pevent_alloc, pevent_free, pevent_event_info and pevent_func_resolver_t
Signed-off-by: NTzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Yordan Karadzhov (VMware) <y.karadz@gmail.com>
Cc: linux-trace-devel@vger.kernel.org
Link: http://lkml.kernel.org/r/20180808180700.152609945@goodmis.orgSigned-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

In order to make libtraceevent into a proper library, variables, data
structures and functions require a unique prefix to prevent name space
conflicts. That prefix will be "tep_" and not "pevent_". This changes
the pevent plugin related API.
Signed-off-by: NTzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Yordan Karadzhov (VMware) <y.karadz@gmail.com>
Cc: linux-trace-devel@vger.kernel.org
Link: http://lkml.kernel.org/r/20180808180700.005287044@goodmis.orgSigned-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

In order to make libtraceevent into a proper library, variables, data
structures and functions require a unique prefix to prevent name space
conflicts. That prefix will be "tep_" and not "pevent_". This changes
the 'struct pevent_record' to 'struct tep_record'.
Signed-off-by: NTzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Yordan Karadzhov (VMware) <y.karadz@gmail.com>
Cc: linux-trace-devel@vger.kernel.org
Link: http://lkml.kernel.org/r/20180808180659.866021298@goodmis.orgSigned-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

In order to make libtraceevent into a proper library, variables, data
structures and functions require a unique prefix to prevent name space
conflicts. That prefix will be "tep_" and not "pevent_". This changes
the struct pevent to struct tep_handle.
Signed-off-by: NTzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Yordan Karadzhov (VMware) <y.karadz@gmail.com>
Cc: linux-trace-devel@vger.kernel.org
Link: http://lkml.kernel.org/r/20180808180659.706175783@goodmis.orgSigned-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

When a record has an unrecognized type, an error message is reported,
but it would also be helpful to see the contents of that record. At
least show what it is in hex, instead of just showing a blank line.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/20180112004822.542204577@goodmis.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

The Linux kernel printf() has some extended use cases that dereference
the pointer. This is dangerouse for tracing because the pointer that is
dereferenced can change or even be unmapped. It also causes issues when
the trace data is extracted, because user space does not have access to
the contents of the pointer even if it still exists.

To handle this, the kernel was updated to process these dereferenced
pointers at the time they are recorded, and not post processed. Now they
exist in the tracing buffer, and no dereference is needed at the time of
reading the trace.

The event parsing library needs to handle this new case.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/20180112004822.403349289@goodmis.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

When processing %pX in pretty_print(), simplify the logic slightly by
incrementing the ptr to the format string if isalnum(ptr[1]) is true.
This follows the logic a bit more closely to what is in the kernel.

Also, this fixes a small bug where %pF was not giving the offset of the
function.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/20180112004822.260262257@goodmis.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Aligns trace-cmd with the behavior of the kernel.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/e60c889f-55e7-4ee8-0e50-151e435ffd8c@siemens.com
Link: http://lkml.kernel.org/r/20180112004822.118332436@goodmis.orgSigned-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

If the value contains bits that are not defined by print_flags() helper,
then show the remaining bits. This aligns with the functionality of the
kernel.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/e60c889f-55e7-4ee8-0e50-151e435ffd8c@siemens.com
Link: http://lkml.kernel.org/r/20180112004821.976225232@goodmis.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Older kernels have a bug that creates invalid symbols. event-parse.c
handles them by replacing them with a "%s" token. But the fix included
an extra backslash, and "\%s" was added incorrectly.
Signed-off-by: NMichael Sartain <mikesart@fastmail.com>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/20180112004821.827168881@goodmis.org
Link: http://lkml.kernel.org/r/d320000d37c10ce0912851e1fb78d1e0c946bcd9.1497486273.git.mikesart@fastmail.comSigned-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Fix the typo of the function name pevent_data_prempt_count()
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Fixes: c52d9e4e ("tools lib traceevent: Add retrieval of preempt count and latency flags")
Link: http://lkml.kernel.org/r/20170216201352.469c99de@grimm.local.homeSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Add support for the __print_hex_str() macro that was added for
tracing, so that user space tools such as perf can understand
it as well.
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add a way to retrieve the preempt count as well as the latency flags from a
pevent_record.

  int pevent_data_preempt_count(pevent, record);

returns the preempt count of a record.

  int pevent_data_flags(pevent, record);

returns the latency flags for a record.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/20161122113158.03a010a8@gandalf.local.homeSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Instead of using 1000000, use the define in time64.h instead.

Also remove the the duplicate defines for NSECS_PER_SEC.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Link: http://lkml.kernel.org/r/20161121114149.67111981@gandalf.local.homeSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

We need to include netinet/in.h to get the in6_addr struct definition, needed to
build it on the Android NDK:

  In file included from event-parse.c:36:0:
  /home/acme/android/android-ndk-r12/platforms/android-24/arch-arm/usr/include/netinet/ip6.h:82:18: error: field 'ip6_src' has incomplete type
    struct in6_addr ip6_src; /* source address */

And it is the canonical way of getting IPv6 definitions, as described,
for instance, in Linux's 'man ipv6'

Doing that uncovers another problem: this source file uses PRIu64 but
doesn't include it, depending on it being included by chance via the now
replaced header (netinet/ip6.h), fix it.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Chris Phlipot <cphlipot0@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-tilr31n3yaba1whsd47qlwa3@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

To make it portable to non-glibc systems, that follow the XSI variant
instead of the GNU specific one that gets in place when _GNU_SOURCE is
defined.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-c1gn8x978qfop65m510wy43o@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Commit a6745330 ("tools lib traceevent: Split pevent_print_event()
into specific functionality functions") broke apart the function
pevent_print_event() into three functions.

The first function prints the comm, pid and CPU, the second prints the
timestamp.

But that commit added the printing of the CPU in the timestamp function,
which now causes pevent_print_event() to duplicate the CPU output.

Remove the redundant printing of the record's CPU from the timestamp
function.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Fixes: a6745330 ("tools lib traceevent: Split pevent_print_event() into specific functionality functions")
Link: http://lkml.kernel.org/r/20160323101628.459375d2@gandalf.local.homeSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

When evaluating values for print flags, if the value included a '~'
operator, the parsing would fail. This broke kmalloc's parsing of:

__print_flags(REC->gfp_flags, "|", {(unsigned
long)((((((( gfp_t)(0x400000u|0x2000000u)) | (( gfp_t)0x40u) |
(( gfp_t)0x80u) | (( gfp_t)0x20000u)) | (( gfp_t)0x02u)) |
(( gfp_t)0x08u)) | (( gfp_t)0x4000u) | (( gfp_t)0x10000u) |
(( gfp_t)0x1000u) | (( gfp_t)0x200u)) & ~(( gfp_t)0x2000000u))
                                        ^
                                        |
                                      here
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Reported-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Tested-by: NDavid Ahern <dsahern@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/20160226181328.22f47129@gandalf.local.homeSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.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>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/20160209204237.337024613@goodmis.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Had a bug where on error of parsing __print_array() where the fields are
freed after they were allocated, but since they were not set to NULL,
the freeing of the arg also tried to free the already freed fields
causing a double free.

Fix process_hex() while at it.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/20160209204237.188327674@goodmis.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

When rounding to microseconds, if the timestamp subsecond is between
.999999500 and .999999999, it is rounded to .1000000, when it should
instead increment the second counter due to the overflow.

For example, if the timestamp is 1234.999999501 instead of seeing:

  1235.000000

we see:

  1234.1000000
Signed-off-by: NChaos.Chen <rainboy1215@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/20160209204236.824426460@goodmis.org
[ fixed incrementing "secs" instead of decrementing it ]
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Currently there's a single function that is used to display a record's
data in human readable format. That's pevent_print_event().
Unfortunately, this gives little room for adding other output within the
line without updating that function call.

I've decided to split that function into 3 parts.

 pevent_print_event_task() which prints the task comm, pid and the CPU
 pevent_print_event_time() which outputs the record's timestamp
 pevent_print_event_data() which outputs the rest of the event data.

pevent_print_event() now simply calls these three functions.

To save time from doing the search for event from the record's type, I
created a new helper function called pevent_find_event_by_record(),
which returns the record's event, and this event has to be passed to the
above functions.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20160229090128.43a56704@gandalf.local.homeSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

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>