mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-12-09 04:21:49 +08:00
976f16630b
In aarch64_tls_transition_without_check and elfNN_aarch64_tls_relax we choose whether to perform a relaxation to an IE access model or an LE access model based on whether the symbol itself is marked as local (i.e. `h == NULL`). This is problematic in two ways. The first is that sometimes a global dynamic access can be relaxed to an initial exec access when creating a shared library, and if that happens on a local symbol then we currently relax it to a local exec access instead. This usually does not happen since we only relax an access if aarch64_can_relax_tls returns true and aarch64_can_relax_tls does not have the same problem. However, it can happen when we have seen both an IE and GD access on the same symbol. This case is exercised in the newly added testcase tls-relax-gd-ie-2. The second problem is that deciding based on whether the symbol is local misses the case when the symbol is global but is still non-interposable and known to be located in the executable. This happens on all global symbols in executables. This case is exercised in the newly added testcase tls-relax-ie-le-4. Here we adjust the condition we base our relaxation on so that we relax to local-exec if we are creating an executable and the relevant symbol we're accessing is stored inside that executable. -- Updating tests for new relaxation criteria Many of the tests added to check our relaxation to IE were implemented by taking advantage of the fact that we did not relax a global symbol defined in an executable. Since a global symbol defined in an executable is still not interposable, we know that a TLS version of such a symbol will be in the main TLS block. This means that we can perform a stronger relaxation on such symbols and relax their accesses to a local-exec access. Hence we have to update all tests that relied on the older suboptimal decision making. The two cases when we still would want to relax a general dynamic access to an initial exec one are: 1) When in a shared library and accessing a symbol which we have already seen accessed with an initial exec access sequence. 2) When in an executable and accessing a symbol defined in a shared library. Both of these require shared library support, which means that these tests are now only available on targets with that. I have chosen to switch the existing testcases from a plain executable to one dynamically linked to a shared object as that doesn't require changing the testcases quite so much (just requires accessing a different variable rather than requiring adding another code sequence). The tls-relax-all testcase was an outlier to the above approach, since it included a general dynamic access to both a local and global symbol and inspected for the difference accordingly.
28 lines
854 B
Makefile
28 lines
854 B
Makefile
# The linker recognises that if we have one IE access to a TLS symbol then all
|
|
# accesses to that symbol could be IE. Here we are also interested to check
|
|
# the linker does not also decide that a second access to that symbol could be
|
|
# LE.
|
|
#target: [check_shared_lib_support]
|
|
#ld: -shared
|
|
#objdump: -dr
|
|
|
|
.*: file format .*
|
|
|
|
|
|
Disassembly of section \.text:
|
|
|
|
[0-9a-f]+ <foo>:
|
|
+[0-9a-f]+: d2800000 mov x0, #0x0 // #0
|
|
+[0-9a-f]+: d53bd041 mrs x1, tpidr_el0
|
|
+[0-9a-f]+: .* adrp x0, .*
|
|
+[0-9a-f]+: .* ldr x0, \[x0, #.*\]
|
|
+[0-9a-f]+: b8606820 ldr w0, \[x1, x0\]
|
|
+[0-9a-f]+: d53bd041 mrs x1, tpidr_el0
|
|
+[0-9a-f]+: 910003fd mov x29, sp
|
|
+[0-9a-f]+: .* adrp x0, .*
|
|
+[0-9a-f]+: .* ldr x0, \[x0, #.*\]
|
|
+[0-9a-f]+: d503201f nop
|
|
+[0-9a-f]+: d503201f nop
|
|
+[0-9a-f]+: b8606820 ldr w0, \[x1, x0\]
|
|
+[0-9a-f]+: d65f03c0 ret
|