search for: __tls_get_addr

I'd like to convert the following call A at GDPLT //R_HEX_GD_PLT_B22_PCREL to call __tls_get_addr //R_HEX_B22_PCREL "A" is a TLS variable and preceding code has prepared for the call. When the R_HEX_GD_PLT_B22_PCREL is found it will initially point to the TLS variable so at that point I'd like to define a __tls_get_addr symbol and update the relocation's type and symbol to...

...to lld based off the existing x86_64 code that is already there in lld. I've been able to compile and link a simple "Hello World"-type program. However, I'm getting what appears to be a misplacement/name change of the _start atom. When I do the link, the _start section gets named __tls_get_addr. The code inside this section appears to be correct, just the name is wrong. If I output in YAML, it appears to have the correct name. Since I know this is new code that no one has seen, I was just wondering if anyone might give me a hint as to why this might happen or a good place to start lo...

...4/power7/libc.so.6+0x16657c) SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/seurer/llvm/llvm-test/projects/compiler-rt/test/msan/dtls_test.c:22:7 in Thread1 Exiting If I run it on an older system with glic 2.17 installed and turn on msan debug verbosity to 2 I see this: ==100505==__tls_get_addr: DTLS_Resize 0x3fff9e1aebf0 0 ==100505==__tls_get_addr: 0x3fff9e4dff38 {0x000000000003,0xffffffffffff8000} => 0x3fff9d8b0000; tls_beg: 0x3fff9d8b0000; sp: 0x3fff9e1ad740 num_live_dtls 1 ==100505==__tls_get_addr: glibc <=2.18 suspected; tls={0x3fff9d8b0000,0x000000100000} stack: 0x3fff9e1ad...

Hi, I've encountered a newly introduced bug in lld today. I am building my program with clang and lld on an X86-64 Ubuntu Linux machine. Command line: clang main.c The compiled program invokes the "main" function multiple times until it closes with a segmentation fault. This affects even the most primitive programs like "int main() { return 0; }". The problem

>> Do you know what is the rationale for that? The static linker will >> optimize it anyway (but not do as good a job as the compiler could). > > codegen can be more efficient. E.g. less or no calls to __tls_get_addr > needed. My point also :-) What I was asking for a rationale on was *not* doing the optimization in the compiler. > Joerg Cheers, Rafael

On Thu, 2019-01-24 at 19:58 +0100, Dimitry Andric via Release-testers wrote: > On 24 Jan 2019, at 01:49, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: > > > > 8.0.0-rc1 was just tagged (from the branch at r351980). > > > > It took a little longer than planned, but it's looking good. > > > > Please run the test

...t; On Thu, Oct 31, 2019 at 8:50 AM kamlesh kumar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Devs, >> Consider testcase here >> https://godbolt.org/z/qHZzqw >> When optimization is O1 or above it produces unoptimized code >> because it calls __tls_get_address in loops. >> While with optimization disabled >> It produce single call to __tls_get_address outside of loop. >> is this a missed optimization by llvm? >> > > It's interesting to me that there's a big difference in -fpie and -fpic. > > https://godbolt....

...it even adds support > > for doing globadynamic in non-PIC code). GCC does the same. > > Do you know what is the rationale for that? The static linker will > optimize it anyway (but not do as good a job as the compiler could). codegen can be more efficient. E.g. less or no calls to __tls_get_addr needed. Joerg

..., Jun 12, 2012 at 12:36:28PM -0400, Rafael Espíndola wrote: > >> Do you know what is the rationale for that? The static linker will > >> optimize it anyway (but not do as good a job as the compiler could). > > > > codegen can be more efficient. E.g. less or no calls to __tls_get_addr > > needed. > > My point also :-) What I was asking for a rationale on was *not* doing > the optimization in the compiler. Ah, sorry. Because the compiler might not know it yet. Consider linking code compiled with -fPIC into the main binary, either using PIE or not. Joerg

Hi Devs, Consider testcase here https://godbolt.org/z/qHZzqw When optimization is O1 or above it produces unoptimized code because it calls __tls_get_address in loops. While with optimization disabled It produce single call to __tls_get_address outside of loop. is this a missed optimization by llvm? ./Kamlesh

...t 12:36:28PM -0400, Rafael Espíndola wrote: >> >> Do you know what is the rationale for that? The static linker will >> >> optimize it anyway (but not do as good a job as the compiler could). >> > >> > codegen can be more efficient. E.g. less or no calls to __tls_get_addr >> > needed. >> >> My point also :-) What I was asking for a rationale on was *not* doing >> the optimization in the compiler. > > Ah, sorry. Because the compiler might not know it yet. Consider linking > code compiled with -fPIC into the main binary, either usin...

> I thought it was a good idea to make the user's choice explicit in the > IR. If we combined the default and globaldynamic modes, LLVM wouldn't > be able to tell the difference. > > It may or may not be important to be able to tell the difference, but > it would be unfortunate if we'd have to go and change the IR format > later because we limited ourselves here.

...ind libthread_db matching inferior's thread library, thread debugging will not be available. ---Type <return> to continue, or q <return> to quit--- Core was generated by `../corerun -c .. ./hello.exe'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x76f7a410 in __tls_get_addr () from /lib/ld-linux-armhf.so.3 (gdb) thread info No symbol "info" in current context. (gdb) bt #0 0x76f7a410 in __tls_get_addr () from /lib/ld-linux-armhf.so.3 #1 0x7699787c in ClassLoader::LoadTypeHandleForTypeKey_Body(TypeKey*, TypeHandle, ClassLoadLevel) () from /dotnet/runtime.rel...

Hello Clang and LLVM Devs, I have been working to add support for an attribute in clang and LLVM that helps user to guide interprocedural register allocation. But the use case I am having is very limited and thus I belieave it is good to have discussion on this before sending a patch. So for IPRA we have a situation where a function is calling a function which is written in assembly and it is

...9;t do that (tm) > > > > Why not? > > They will be eliminated w/o any visible effect. Hmm...As I said I added them in our 2.5 implementation and they didn't get eliminated. The stack gets properly adjusted and everyone's happy. Our 2.5 implementation creates the call to __tls_get_addr manually in the X86ISelLowering code. In TOT special SDNodes are generated which get matched by TableGen patterns and dump out a fixed sequence of instructions which includes the call. I'm guessing that's the critical difference. Is there a reason that route was taken in TOT? Why have a...

...have to get our hands dirty and implement the necessary ABI/OS-specific functions manually in the language runtime code. Currently, the best idea I have is to: - On Linux, find out the size of the TLS segments by using dl_iterate_phdr on initialization, then add the block of this size starting at __tls_get_addr({module, 0}) on thread initialization. - On OS X, use something similar to the private dyld_enumerate_tlv_storage/dyld_register_tlv_state_change_handler functions in dyld. Is there a better way to do this? Ideally, the solution would be portable across different OSes, but right now I'm happy...

...uns. The JIT'd code just needs to refer to it. OK. Are we generating generic dynamic code to do so? It will look like .byte 0x66 leaq x at tlsgd(%rip),%rdi ; R_X86_64_TLSGD to symbol x (MCJIT has to create a GOT entry) .word 0x6666 rex64 call __tls get_addr at plt ; R_X86_64_PLT32 to __tls_get_addr (MCJIT has to create a GOT and a PLT entry) This should work from any place in memory. I wouldn't be surprised if these relocations are not implemented yet, but that should be all that is needed to get tls working. Cheers, Rafael

Hello, David >> Don't do that (tm) > > Why not? They will be eliminated w/o any visible effect. >> I'm testing the fix. > > Ok, I'll try to "mark noredzone" thing and see if that works. It does, I verified this with the testcase you attached to PR. The problem is not stack allocation, but red zone thing. As I already said, I'm testing the fix;

+ Nick On 2/19/2015 9:00 AM, Shankar Easwaran wrote: > On 2/19/2015 3:58 AM, Denis Protivensky wrote: >> Joerg: >>> I propose to add the ability to ignore undefined symbols during initial >>> resolution, and then postprocess only those undefines for the second >>> time >>> after the pass manager execution. >> Do you want to do that before or

Hi what do you guys use for shared calendars these days? I've been using corporate time but that is now part of Oracle suite so looking for an alternative that is hopefully open source/free to complete my 'get away from exchange' package. thanks