X86/X86-64 linkers check code sequence while performing TLS optimization like: /* IE->LE transition: Originally it can be one of: movq foo@gottpoff(%rip), %reg addq foo@gottpoff(%rip), %reg We change it into: movq $foo, %reg leaq foo(%reg), %reg addq $foo, %reg. */ BFD_ASSERT (rel->r_offset >= 3); val = bfd_get_8 (input_bfd, contents + rel->r_offset - 3); BFD_ASSERT (val == 0x48 || val == 0x4c); type = bfd_get_8 (input_bfd, contents + rel->r_offset - 2); BFD_ASSERT (type == 0x8b || type == 0x03); reg = bfd_get_8 (input_bfd, contents + rel->r_offset - 1); BFD_ASSERT ((reg & 0xc7) == 5); reg >>= 3; BFD_ASSERT (rel->r_offset + 4 <= input_section->size); But not all TLS code sequences generated by all compilers follow the same sequence. In many cases, such optimization is dangerous and wrong. We should check the code sequence before performing such optimization.
Which compilers violate the TLS ABI? tls.pdf clearly says that the sequences are not optional, if you use the corresponding relocations, you must use them only in the listed sequences.
1. Those sequences may not be optimal in all cases. If compiler knows those optimizations won't be performed, it can generate better sequence. But sometimes compiler may be wrong and we wind up with code sequences which can't not be optimized. 2. Skip those optimizations will not affect the correctness of the program. But performing those optimizations on different sequence will result in bad program. At least, linker shouldn't knowingly generate bad program.
Subject: Re: Linker should check code sequence before TLS optimization On Thu, Aug 16, 2007 at 01:08:34PM -0000, hjl at lucon dot org wrote: > 1. Those sequences may not be optimal in all cases. If compiler knows Then discuss ABI changes, please. ABI documents are not optional to follow!
(In reply to comment #3) > Subject: Re: Linker should check code sequence before TLS > optimization > > On Thu, Aug 16, 2007 at 01:08:34PM -0000, hjl at lucon dot org wrote: > > 1. Those sequences may not be optimal in all cases. If compiler knows > > Then discuss ABI changes, please. ABI documents are not optional to follow! > In this case, linker is generating the final result. This linker "optimization" I am proposing will generate correct output with better performance and without affecting interoperability, which an ABI is used for.
.