This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Patch ARM] Allow R_ARM_TLS_LE32 in PIE Executables.


With a recent change to the GCC testsuite to run tls tests with PIE
I see a few failures when things like run-le.c are built PIE, with an
error message that shared-objects shouldn't contain a LOCAL_EXEC

(I needed a modified gcc-testglue.o built with -fPIC to be able to build these
tests in this form and see these errors. )

Well, if you are creating a PIE executable the static block
for the TLS still exists and the distance between the thread
pointer and the actual thread variable is the same. Thus it shouldn't
matter that you have a R_ARM_TLS_LE32 in a PIE executable being

Testing the simple case (torture/tls/run-le.c) with LOCALEXEC in the testsuite
now allows this to pass. I tried runing a cross test with eglibc
and that didn't appear to show any regressions. I was able to torture
on tls.exp if
I built gcc-testglue.c -fPIC and made this change in the linker.

Ok to commit ? Tested in a cross-configuration with arm-linux-gnueabi with
no regressions.


2011-06-16  Ramana Radhakrishnan  <>

	* elf32-arm.c (elf32_arm_final_link_relocate): Allow R_ARM_TLS_LE32
	for PIE.
 bfd/elf32-arm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/bfd/elf32-arm.c b/bfd/elf32-arm.c
index b0f315b..257f7a5 100644
--- a/bfd/elf32-arm.c
+++ b/bfd/elf32-arm.c
@@ -9454,7 +9454,7 @@ elf32_arm_final_link_relocate (reloc_howto_type
*           howto,

     case R_ARM_TLS_LE32:
-      if (info->shared)
+      if (info->shared && !info->pie)
 	    (_("%B(%A+0x%lx): R_ARM_TLS_LE32 relocation not permitted in
shared object"),

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]