[lttng-dev] TRACEPOINT_PROVIDER mismatch check in ust-tracepoint-event.h needs -Wsystem-headers

[Mathieu Desnoyers]

* David OShea (David.OShea at quantum.com) wrote:
> Hi Mathieu,
> 
> Thanks for the response and apologies for the delay in mine, please see below:
> 
> > -----Original Message-----
> > From: Mathieu Desnoyers [mailto:mathieu.desnoyers at efficios.com]
> > Sent: Tuesday, 20 November 2012 2:56 AM
> > To: David OShea
> > Cc: lttng-dev at lists.lttng.org
> > Subject: Re: [lttng-dev] TRACEPOINT_PROVIDER mismatch check in ust-
> > tracepoint-event.h needs -Wsystem-headers
> [...]
> > > I'm not sure if there is any way you could "fix" this so that
> > > -Wsystem-headers isn't required, but perhaps it would at least be
> > > worth documenting that this flag could be used - but perhaps not
> > > recommend it - to enable those checks to occur.
> > 
> > I have not found any way to show those warnings from UST system headers
> > without -Wsystem-headers. We have the following scenario:
> > 
> > probe C file
> >   -> includes ust probe description file
> >      -> includes tracepoint-event.h (system header)
> >         -> includes ust probe description file
> >         -> includes ust-tracepoint-event.h (system header) [1]
> >            For each stage:
> >              -> undef/define macros
> >              -> includes ust probe description file
> > 
> > Since the actual functions are created by the compiler in the scope of
> > ust-tracepoint-event.h [1] (a system header), the warnings are
> > inhibited
> > unless we specify -Wsystem-headers.
> [...]
> > So I guess documenting this would be the right way to do it, unless
> > anyone has a better idea ?
> 
> I don't know much about the macros in ust-tracepoint-event.h, so this
> might not make any sense, but could you have the
> __tracepoint_provider_check_##TRACEPOINT_PROVIDER() function actually
> get called from the __lttng_events_init__##TRACEPOINT_PROVIDER()
> (constructor) function?  I assume this would mean you'd get link-time
> errors if you have a provider name mismatch.  It would also mean a lot
> of useless calls to empty functions at startup, but I assume that
> really shouldn't take too long.  Perhaps this checking could be a
> compile-time option, so that if you're concerned about the startup
> time impact you can disable it, or perhaps the functions could be
> marked as inline?

That makes sense!

Can you try the following patch and let me know if it fixes your
problem?

Thanks,

Mathieu

commit f26441658685b281756ccbc8f74d70b9f2e6dad5
Author: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
Date:   Mon Nov 26 15:14:24 2012 -0500

    Print probe provider mismatch error even without -Wsystem-headers
    
    Suggested-by: David OShea <David.OShea at quantum.com>
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>

diff --git a/include/lttng/ust-tracepoint-event.h b/include/lttng/ust-tracepoint-event.h
index 8f804d6..c341e04 100644
--- a/include/lttng/ust-tracepoint-event.h
+++ b/include/lttng/ust-tracepoint-event.h
@@ -72,7 +72,7 @@ void _TP_COMBINE_TOKENS(__tracepoint_provider_mismatch_, TRACEPOINT_PROVIDER)(vo
 #define TRACEPOINT_EVENT_INSTANCE(_provider, _template, _name, _args)	\
 	__tracepoint_provider_mismatch_##_provider();
 
-static __attribute__((unused))
+static inline
 void _TP_COMBINE_TOKENS(__tracepoint_provider_check_, TRACEPOINT_PROVIDER)(void)
 {
 #include TRACEPOINT_INCLUDE
@@ -655,6 +655,15 @@ _TP_COMBINE_TOKENS(__lttng_events_init__, TRACEPOINT_PROVIDER)(void)
 {
 	int ret;
 
+	/*
+	 * __tracepoint_provider_check_ ## TRACEPOINT_PROVIDER() is a
+	 * static inline function that ensures every probe PROVIDER
+	 * argument match the provider within which they appear. It
+	 * calls empty static inline functions, and therefore has no
+	 * runtime effect. However, if it detects an error, a linker
+	 * error will appear.
+	 */
+	_TP_COMBINE_TOKENS(__tracepoint_provider_check_, TRACEPOINT_PROVIDER)();
 	ret = lttng_probe_register(&_TP_COMBINE_TOKENS(__probe_desc___, TRACEPOINT_PROVIDER));
 	assert(!ret);
 }
-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com