Musl does support TLS in shared objects

Description

f895e3bbf3076ed87fd87af3e4ea7de7db7b34a8 says "Musl libC doesn't support dynamically loaded binaries having TLS relocations", which is not correct. musl doesn't support dynamically loaded libraries with initial-exec TLS. dynamically loaded libraries need to use global-dynamic or local-dynamic TLS models, which can be selected in gcc by passing -fpic flag.

Example

https://godbolt.org/z/E4c3WWohq

static __thread void *cur_ex_ptr;
void **eh_get_exception_ptr(void) {
    return &cur_ex_ptr;
}

gcc -O2, bad:

eh_get_exception_ptr:
        mov     rax, QWORD PTR fs:0
        add     rax, OFFSET FLAT:cur_ex_ptr@tpoff
        ret
cur_ex_ptr:
        .zero   8

gcc -O2 -fpic, good:

eh_get_exception_ptr:
        sub     rsp, 8
        lea     rdi, cur_ex_ptr@tlsld[rip]
        call    __tls_get_addr@PLT
        add     rsp, 8
        add     rax, OFFSET FLAT:cur_ex_ptr@dtpoff
        ret
cur_ex_ptr:
        .zero   8

Note that __tls_get_addr may clobber callee-saved registers. -mtls-dialect=gnu2 can avoid that, but needs assembler+linker+libc support. glibc supports it since ~2008, so it's probably OK for MonoMod to use?

Start by reviewing commit f895e3bbf3076ed87fd87af3e4ea7de7db7b34a8 and the GCC TLS examples in the issue. Determine which MonoMod behavior or statement needs updating, then verify the result against musl's supported TLS models and the linked compiler example.