On 06-08-2025 13:39, Steven Rostedt wrote:
On Wed, 6 Aug 2025 11:24:33 +0100
Douglas Raillard <[email protected]> wrote:
On 05-08-2025 20:26, Steven Rostedt wrote:
From: Steven Rostedt <[email protected]>
Currently the syscall trace events show each value as hexadecimal, but
without adding "0x" it can be confusing:
sys_write(fd: 4, buf: 0x55c4a1fa9270, count: 44)
Looks like the above write wrote 44 bytes, when in reality it wrote 68
bytes.
Add a "0x" for all values greater or equal to 10 to remove the ambiguity.
For values less than 10, leave off the "0x" as that just adds noise to the
output.
I'm on the fence for the value-dependent format. This looks like
it could easily make life harder for quick&dirty scripts, but then both
awk's strtonum() and Python's int(x, base=16) seem to handle
the presence/absence of the 0x prefix so maybe it's a non-issue.
Yes, but the trace file is more for humans than scripts, and the 0x1 is
just noise.
OTH, a hand-crafted regex designed after a small set of input may start
to randomly fail if one field unexpectedly goes beyond 10 ...
If you are doing hand crafted scripts, I'd suggest to use tracing
filters or other tooling that can handle this easily ;-)
Well, we both know I don't do this sort of things (or do I ? :) ) but for
the first 5+ years of its existence, LISA was actually parsing the text
output of trace-cmd, and I'd be surprised if it was the only place this was
done.
AFAIK to this day, there is no tool providing a simple script/SQL interface
to a trace.dat file beyond basic filtering like trace-cmd report. I've had this
PR [1] opened for a while in LISA that does exactly that but got distracted with
other things:
# Show all the CPUs that emitted a cpu_frequency event
lisa-trace sql trace.dat --query 'SELECT DISTINCT cpu_id FROM cpu_frequency'
shape: (8, 1)
┌────────┐
│ cpu_id │
│ --- │
│ u32 │
╞════════╡
│ 0 │
│ 1 │
│ 2 │
│ 3 │
│ 7 │
│ 4 │
│ 5 │
│ 6 │
└────────┘
[1] https://gitlab.arm.com/tooling/lisa/-/merge_requests/2444
Just using explicit hex may be the best here, as the actual proper fix
(type-level display hints) is harder. It could probably be implemented
using btf_decl_tag() and __builtin_btf_type_id() to retrieve the BTF info.
That would add a dependency on BTF, which I would like to avoid.
Thanks!
-- Steve
--
Douglas
