TLS for Android
code at klickverbot.at
Sat Mar 8 14:44:05 PST 2014
On Sat, Mar 8, 2014 at 7:16 PM, Joakim <joakim at airpost.net> wrote:
> On Saturday, 8 March 2014 at 14:25:43 UTC, David Nadlinger wrote:
>> LLVM does support putting variables into custom sections, and you can more
>> or less get away with the DMD bracketing approach (see e.g. the new
>> ModuleInfo discovery functionality I implemented for Linux, which is the
>> same as DMD's druntime uses).
> You're talking about findDataSection and friends?
Not quite. I was referring to
(_d_dso_registry, ...) and the associated compiler-side
>> However, there is a catch: Due to what I can only imagine is a bug, LLVM
>> does not support emitting a symbol both into a custom section and with weak
>> linkage. Thus, you might be in for a round of LLVM hacking either way, even
>> though it will likely involve much less when going the DMD route.
> Hmm, I guess this is why you don't use the bracketing approach anywhere?
> What will be much less when going the DMD route?
Actually, we didn't use the special section approach at all until very
recently (i.e. Martin's shared library changes in 2.064). And I meant
that you would probably get away with less LLVM hacking when just
changing the way LDC emits TLS globals/accesses than when implementing
"emulated" TLS on the LLVM backend side.
> As for reimplementing the runtime linker, in a sense that's what's being
> done with dmd/druntime for OS X, where it implements it's own
> ___tls_get_addr using pthread_setspecific. I'll have to do the same for
> Android, as bionic doesn't have a __tls_get_addr.
Well, yes and no. I was specifically referring to keeping the normal
TLS infrastructure (i.e. %gs-based addressing on Linux/x86) in place
and just replacing the part that Glibc does (but Bionic doesn't) with
a piece of code in druntime. __tls_get_addr isn't necessarily used on
More information about the digitalmars-d-ldc