Hi David, I will look into this at earliest and provide feedback.
Thanks From: David Marchand <david.march...@redhat.com> Sent: Friday, February 7, 2025 2:20 PM To: Jerin Jacob <jer...@marvell.com>; Sunil Kumar Kori <sk...@marvell.com> Cc: dev@dpdk.org; Chengwen Feng <fengcheng...@huawei.com>; Kevin Laatz <kevin.la...@intel.com>; Bruce Richardson <bruce.richard...@intel.com>; Tyler Retzlaff <roret...@linux.microsoft.com>; Andre Muezerie <andre...@linux.microsoft.com>; Thomas Monjalon <tho...@monjalon.net>; Stephen Hemminger <step...@networkplumber.org> Subject: [EXTERNAL] Re: [PATCH v2 3/3] trace: fix undefined behavior in register Hello Jerin, Sunil, On Thu, Jan 30, 2025 at 3: 59 PM David Marchand <david. marchand@ redhat. com> wrote: > > Registering a tracepoint handler was resulting so far in undefined > behavior at runtime. > > The RTE_TRACE_POINT_REGISTER() Hello Jerin, Sunil, On Thu, Jan 30, 2025 at 3:59 PM David Marchand <david.march...@redhat.com<mailto:david.march...@redhat.com>> wrote: > > Registering a tracepoint handler was resulting so far in undefined > behavior at runtime. > > The RTE_TRACE_POINT_REGISTER() macro was casting the tracepoint handler > (which expects arguments) to a void (*)(void). > At runtime, calling this handler while registering resulted in > reading the current stack with no relation to this function prototype. > > Instead, declare an additional inline _register() handler for each > tracepoint and make sure that the emitting macros in > rte_trace_point_register.h only work on arguments name and type. > > The original tracepoint handler prototype is adjusted by adding a > __rte_unused for each argument (since emitting macros do nothing > with them). > This last part introduces an implementation limit of 15 arguments. > > With this change in place, the workaround in dmadev tracepoints can be > removed. > > Signed-off-by: David Marchand > <david.march...@redhat.com<mailto:david.march...@redhat.com>> Can I have your opinion and review on this patch? Thanks. -- David Marchand
