This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC PATCH glibc] pthread_setspecific: Provide signal-safety across keys


----- On Oct 18, 2017, at 1:36 AM, Florian Weimer fw@deneb.enyo.de wrote:

> * Mathieu Desnoyers:
> 
>> ----- On Oct 17, 2017, at 6:19 PM, Florian Weimer fw@deneb.enyo.de wrote:
>>
>>> * Mathieu Desnoyers:
>>> 
>>>>> Then you really need to switch to real thread-local variables with the
>>>>> intial-exec model, possibly with indirection through a thread-local
>>>>> pointer variable and on-demand allocation using mmap in case you do
>>>>> not want to have these allocations in every thread.
>>>>
>>>> Actually, liburcu-bp, which is the library actually using
>>>> pthread_setspecific, does use a TLS pointer to a mmap'd region.
>>>>
>>>> The __thread variable sits in a library shared object, so it's not
>>>> possible to use the initial-exec model.
>>> 
>>> glibc supports this, and there shouldn't be any issues if the library
>>> is loaded into the initial process image (LD_PRELOAD or DT_NEEDED
>>> reference).  dlopen can be problematic, though.  With current
>>> upstream, additional initial-exec TLS variables do not impact later
>>> dlopen.  (This was not always true.)
>>
>> Unfortunately, it is allowed to dlopen() the lttng-ust tracer library
>> as well.
> 
> The question is whether this is a common use case, or if it is
> acceptable to have somewhat limited support for this (in the sense
> that if you dlopen many different libraries which use initial-exec
> TLS, you might see a failure eventually).

My use-case is a library called from an application or library instrumentation.
The objective is to minimally change the application/library (basically only
instrument it). It should be possible to only instrument and trace a
linked .so without changing the application.

I need the tracer to run fine in a signal handler, and it happens to
use TLS variables.

I would assume this use-case is not so common, as the requirement
of being used in a signal handler is more specific to a tracer than
a generic library.

So let's assume dlopen failure is acceptable if there are too many
initial-exec TLS. Would it work today to fix signal handler tracing
by changing lttng-ust to use TLS_IE, or would it require changes to
glibc ?

Thanks,

Mathieu


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]