Re: traceevent support for kernels with CONFIG_GCC_PLUGIN_STRUCTLEAK=y

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 12 Dec 2019 19:07:46 +0200
John Koepi <john.koepi@gmail.com> wrote:

> > $ cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_io_submit/format
> > name: sys_enter_io_submit
> > ID: 897
> > format:
> > field:unsigned short common_type; offset:0; size:2; signed:0;
> > ...
> > field:struct iocb __attribute__((user)) * __attribute__((user)) * iocbpp; offset:32; size:8; signed:0;
> > ...  
> 
> Having __attribute__ leaked into syscalls format, it makes its
> impossible for the traceevent lib from the kernel/tools/lib to
> parse such fields, like in the example above.
> 
> This in its turn makes it impossible to use tracing for those syscalls:
> 
> > $ sudo perf record -e syscalls:sys_enter_io_submit -aR
> > libtraceevent: No such file or directory
> >  Error: expected type 4 but read 5  
> 
> Thus, tracing does not work for some syscalls in Arch Linux kernels.
> And I suppose for all kernels that built with structleak plugin support.
> 
> Reproduce: https://github.com/sitano/traceevent_attribute
> 
> My question:
> 
> Is it a bug that the traceevent lib does not support parsing __attribute__
> in syscalls formats?
> 
> or it is a bug of the SYSCALL_DEFINEx macroses / build system that
> they do allow C attributes to leak?
> 
> maybe this is already fixed in the latest kernel? or maybe I am missing
> something?

Thanks for the report. This looks like something we can have
libtraceveent handle, no need to change the kernel.

Could you file a bug report?

  https://bugzilla.kernel.org/buglist.cgi?component=Trace-cmd%2FKernelshark&product=Tools&resolution=---

-- Steve