[lttng-dev] [PATCH lttng-ust] Fix: remove weak attribute from __start___tracepoints_ptrs and __stop___tracepoints_ptrs

Mathieu Desnoyers mathieu.desnoyers at efficios.com
Thu Jun 5 13:27:06 EDT 2014


----- Original Message -----
> From: "Gerlando Falauto" <gerlando.falauto at keymile.com>
> To: lttng-dev at lists.lttng.org
> Cc: "Gerlando Falauto" <gerlando.falauto at keymile.com>
> Sent: Wednesday, May 28, 2014 7:05:52 PM
> Subject: [lttng-dev] [PATCH lttng-ust] Fix: remove weak attribute from	__start___tracepoints_ptrs and
> __stop___tracepoints_ptrs
> 
> Some OpenEmbedded GCC releases (namely 4.7.2) incorrectly emit those
> symbols with default visibility if both weak and hidden attributes
> are used.
> When tracepoints are distributed among the main application and one or
> several shared objects (e.g. lttng_ust_tracef:event in liblttng-ust.so
> AND your own tracepoint provider, statically or dynamically linked),
> this results in a subtle name clash at runtime, causing only the
> tracepoints from one particular binary to be active, silently breaking
> all others.
> These symbols are indeed only declared and need not be defined (contrary
> to __tracepoint_registered and friends), as they are automatically
> PROVIDE-d by the linker as pointers to the "_tracepoint_ptrs" orphaned
> section.

Does it work well if the program and/or libraries do the following:

- they include tracepoint.h,
- but they don't contain any tracepoint (so there is technically no
  _tracepoint_ptrs section)

Has this case been tested ? I remember that the weak was there for this
peculiar corner case.

Thanks,

Mathieu

> 
> So even though the issue is only observed with a buggy compiler, removing
> the weak attribute also enforces the correct strong linking to the symbols
> provided by the linker (which would otherwise, by weak semantics, default
> to a value of all-zeroes).
> 
> References: https://gcc.gnu.org/ml/gcc-help/2014-05/msg00005.html
> References: http://lists.lttng.org/pipermail/lttng-dev/2014-May/023090.html
> Reported-by: Martin Ünsal <martinunsal at gmail.com>
> Thanks-to: Henrik Wallin <henrikwallin72 at gmail.com>
> Cc: Paul Woegerer <Paul_Woegerer at mentor.com>
> Signed-off-by: Gerlando Falauto <gerlando.falauto at keymile.com>
> ---
>  include/lttng/tracepoint.h | 15 ++++++++++-----
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/include/lttng/tracepoint.h b/include/lttng/tracepoint.h
> index c5a09d8..229ea72 100644
> --- a/include/lttng/tracepoint.h
> +++ b/include/lttng/tracepoint.h
> @@ -308,14 +308,19 @@ __tracepoints__destroy(void)
>  #ifdef TRACEPOINT_DEFINE
>  
>  /*
> - * These weak symbols, the constructor, and destructor take care of
> - * registering only _one_ instance of the tracepoints per shared-ojbect
> - * (or for the whole main program).
> + * These strong hidden symbols are automatically provided by the linker
> + * for each shared-object (or for the whole main program) as pointers
> + * to the orphaned section "_tracepoints_ptrs" and must not be visible
> + * from other shared objects to avoid name clashes at runtime which would
> + * silently enable only the tracepoints from the object loaded first.
> + * NOTICE: Some OpenEmbedded GCC releases (namely 4.7.2) incorrectly
> + * emit those symbols with default visibility if both weak and hidden
> + * are used.
>   */
>  extern struct tracepoint * const __start___tracepoints_ptrs[]
> -	__attribute__((weak, visibility("hidden")));
> +	__attribute__((visibility("hidden")));
>  extern struct tracepoint * const __stop___tracepoints_ptrs[]
> -	__attribute__((weak, visibility("hidden")));
> +	__attribute__((visibility("hidden")));
>  
>  /*
>   * When TRACEPOINT_PROBE_DYNAMIC_LINKAGE is defined, we do not emit a
> --
> 1.8.0.1
> 
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com



More information about the lttng-dev mailing list