[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/22570] New: ld fails to bind DTPMOD at link time for pie on mips
From: |
bugdal at aerifal dot cx |
Subject: |
[Bug ld/22570] New: ld fails to bind DTPMOD at link time for pie on mips |
Date: |
Thu, 07 Dec 2017 22:11:13 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=22570
Bug ID: 22570
Summary: ld fails to bind DTPMOD at link time for pie on mips
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
When a symbol is defined and referenced in the main program, DTPMOD relocations
should be bound at ld time to module 1. This is mandatory for static linking
and merely an optimization in the case of dynamic linking. However the logic in
elfxx-mips.c's mips_elf_initialize_tls_slots() function is not pie-aware, and
uses info->shared rather than !info->executable as the condition for "output is
a shared library", thereby disabling the logic to resolve DTPMOD at link time.
As a result, static pie executables contain a DTPMOD relocation and will not
work without spurious runtime code to resolve it.
Note that this would be a non-issue if mips targets had TLS relaxation, but as
far as I can tell they don't. I suspect the same issue may exist on other
targets that lack relaxations but I was not able to find the corresponding
code.
Simple test case:
__thread int x = 42;
int main() { return x; }
The output, compiled with -fPIC (rather than -fPIE, to ensure that GD model
access is generated) and linked with -pie, should not contain any
R_MIPS_TLS_DTPMOD relocations, but does.
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug ld/22570] New: ld fails to bind DTPMOD at link time for pie on mips,
bugdal at aerifal dot cx <=