On 9/3/24 09:21, Steven Rostedt wrote:
> On Tue, 3 Sep 2024 09:25:12 +0200
> Christoph Hellwig <[email protected]> wrote:
>
>> On Thu, Aug 29, 2024 at 10:24:52AM -0400, Sean Anderson wrote:
>> > >> When debugging drivers, it can often be useful to trace when memory gets
>> > >> (un)mapped for DMA (and can be accessed by the device). Add some
>> > >> tracepoints for this purpose.
>> > >>
>> > >> We use unsigned long long instead of phys_addr_t and dma_addr_t (and
>> > >> similarly %llx instead of %pa) because libtraceevent can't handle
>
> I think the issue is that libtraceevent doesn't handle "%pa", which I can
> fix.
With s/unsigned long long/u64/g I get
kworker/2:1H-mm 183 [002] 32.472411: dma:dma_unmap_sg:
[FAILED TO PARSE] device=ff160000.mmc addrs=ARRAY[00, 50, e2, 06, 08, 00, 00,
00] dir=2 attrs=0x0
>> > >> typedefs.
>> > >
>> > > and a __u64 would seem like the better type here.
>> >
>> > libtraceevent can't handle typedefs, including u64.
>>
>> Weird. The xfs trace events which were some of the first ever are full
>> of typedefs and no one ever complained. And looking at other
>> trace event definitions they are full of it.
>>
>> I've added the tracing maintainers to see if we can shed some light
>> on this issue.
>
> libtraceevent doesn't even really bother with the types. It gets its
> information from the other fields.
>
> For example:
>
> events/x86_fpu/x86_fpu_after_restore/format: field:u64 xfeatures;
> offset:24; size:8; signed:0;
>
>
> The "field:u64" is more for humans than the tools. And it can be used for
> hints when the printfmt fails to parse. But the libtraceevent really looks
> at the "offset", "size" and "signed" to know how to use that number.
This doesn't apply for arrays:
field:__data_loc u64[] addrs; offset:12; size:4; signed:0;
Here the size is not for the data type but for the array. And so the
type is parsed by process_sizeof in src/event-parse.c.
--Sean
