trace-cmd: Correctly handle arrays

[
 Taken from a perf patch.
 I got the OK from Ian Musie to include this under LGPL
]

Previously, perf was assuming that an array from an ftrace event was an
array of longs, which will not always be the case. Additionally,
long_size is not even being initialised, so it would fail to read the
data and would erroneously report that the array was filled with zeroes.

This patch adds two extra entries into the field structure - arraylen
and elementsize, so that the code can easily look them up instead of
assuming that the elements are long_size. The element size is currently
derived by the size of the entire array and the number of elements
within the array.

This problem can be demonstrated with:
perf record -e raw_syscalls:sys_enter -a sleep 0.1
perf trace

Without this patch, output similar to the following is produced:
 perf-4355  [004]  1871.504685: sys_enter: NR 319 (0, 0, 0, 0, 0, 0)
 perf-4355  [004]  1871.504723: sys_enter: NR 3 (0, 0, 0, 0, 0, 0)
 perf-4355  [004]  1871.504733: sys_enter: NR 204 (0, 0, 0, 0, 0, 0)

After applying this patch, the output looks like:
 perf-4355  [004]  1871.504685: sys_enter: NR 319 (10247ac0, ffffffff, 5, ffffffff, 0, 107a80d8)
 perf-4355  [004]  1871.504723: sys_enter: NR 3 (a, ffb6fcf0, 20, ffffffff, 0, 10112c20)
 perf-4355  [004]  1871.504733: sys_enter: NR 204 (a, 4, 800, 6, 0, 10112c20)

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
LKML-Reference: <1273730632-21008-3-git-send-email-imunsie@au1.ibm.com>

[ Fixed array handling ]

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

0 files changed, 0 insertions, 0 deletions