Messages in this thread | | | Date | Tue, 5 Apr 2016 18:47:22 +0200 | From | Peter Zijlstra <> | Subject | Re: [RFC PATCH v6 1/5] Thread-local ABI system call: cache CPU number of running thread |
| |
On Tue, Apr 05, 2016 at 06:02:25PM +0200, Florian Weimer wrote: > On 04/04/2016 10:48 PM, Mathieu Desnoyers wrote: > > > Moreover, the feature set that the application knows about, glibc > > knows about, and the kernel knows about are three different things. > > My intent here is to have glibc stay out of the way as much as possible, > > since this is really an interface between various applications/libraries > > and the kernel. > > Surely glibc can allocate the space based on what is advertised as > needed by the kernel? Why would it limit itself to what is supported by > the kernel headers it is compiled against if the actual size can be > queried from the kernel?
I guess the question is; can we do thread local variable arrays like:
__thread uint32_t[x]; /* with x being a runtime constant */
Because then we can do:
__thread struct thread_local_abi tla;
where sizeof(struct thread_local_abi) is a runtime variable.
Without that we cannot have this thread-local-abi structure be part of the immediately addressable TLS space. That is, we then need a pointer like:
__thread struct thread_local_abi *tla;
and every usage will need the extra pointer deref.
Because ideally this structure would be part of the initial (glibc) TCB with fixed offset etc.
| |