search for: findgotentri

Hi Lang, Yeah, I remember this case. Basically what’s happening is that there are relocations for ELF on x86 that use a value that is present in the object image as part of the calculation for the final value that goes in the same location. If you ever find yourself applying relocations for a second time (for instance, because the loaded object location is remapped for out-of-proc execution)

I'm looking currently into a patch <https://mailtrack.io/trace/link/60b02baa5e1b3d7ffe6fbb428b343be17c58c583?url=https%3A%2F%2Fgithub.com%2FJuliaLang%2Fllvm%2Fcommit%2Fa9e17b7f47f5afa9683fc8cfeff7020b2ff4a8b2%23diff-0fa8ca8690e36a8dfd05f6b751955164R339&signature=222c65b9d92c011f> which has been written for JuliaLang and is supposed to fix TLS for linux. Unfortunately it is based on

Over one year passed now, did anybody made any progress regarding this issue? On 9 February 2017 at 16:33, Gaetano Checinski <gaetano.checinski at gmail.com> wrote: > I'm looking currently into a patch >

[Adding llvm-dev back to list] On 8 February 2017 at 11:12, Gaetano Checinski <gaetano.checinski at gmail.com> wrote: > Thanks for sharing your insights, > so in theory i could build an llvm pass that calls TargetLowering::LowerToTLSEmulatedModel for each llvm::Function and it should work if i link a runtime that provides __emultls_get_address. I'm afraid not, that function is

> Unfortunately it doesn't look like lli has support for emulated TLS either, though that would be pretty simple to add. As an experiment I've `llvm::createLowerEmuTLSPass` into lli which added @__emutls_v.x and @__emutls_v.t. However i didn't have any __emultls_get_address calls in my IR. Is there a llvm pass or compiler-flag that replaces thread_locals with appropriate