Use mmap/munmap for allocating memory in emutls when available.

[andre-kempe-arm]

Hi Saleem (@compnerd )

The patch solves a problem when projects using LLVM implement their own versions of malloc/free but still want to use thread_local storage as we know it from C++. In this case, emutls jumps back into a the user provided version and creates nasty recursions.

The patch resolves this conflict by using mmap and munmap to manage memory in emutls.

Could you have a look at the patch, please? What do you think about it in general? And where can I improve the code?

Thanks a lot for your time and effort.

Best regards,
André

[andre-kempe-arm]

Hi Saleem @compnerd

I just wanted to reach out to you regarding this pull request.

Do you have a chance to have a look at the changes? Or another reviewer who could give me feedback?

Thanks and Best Regards
André

[compnerd]

Apologies, I didn't see the original request in all the GitHub messages.

I think that this is adding a lot of complexity for replacing the memory allocator which can already be done by providing an implementation of malloc/free. This increases the dependency on libc further complicating bootstrapping. Can we instead not provide shims as we did through malloc? For most use cases, emutls must be built into a DSO as static linking is incompatible with dynamically linked environments as you need to single global set of locks. The only way to statically link this is to have a completely statically linked executable where glibc cannot be used as the libc.