https://sourceware.org/bugzilla/show_bug.cgi?id=17699
Bug ID: 17699
Summary: incorrect R_386_TLS_DTPMOD32 relocation
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at google dot com
Reporter: timo.teras at iki dot fi
CC: ian at airs dot com
gold from binutils 2.24 with few CVE patch applied, and compiling gcc 4.9.2's
libstdc++ produce incorrect R_386_TLS_DPT_MOD32 relocation on x86 (on x86_64
and arm the equivalent relocation is produced correctly):
on x86:
The relevant parts of "readelf -a /usr/lib/libstdc++.so.6":
Relocation section '.rel.dyn' at offset 0x4811c contains 2534 entries:
Offset Info Type Sym.Value Sym. Name
...
000d30f8 00000123 R_386_TLS_DTPMOD3 000cfe80 .tbss
...
Symbol table '.dynsym' contains 4207 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 000cfe80 0 SECTION LOCAL DEFAULT 17
...
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf
Al
...
[17] .tbss NOBITS 000cfe80 0cee80 000010 00 WAT 0 0
4
And for reference the equivalent relocation on x86_64 is:
0000000e1240 000000000010 R_X86_64_DTPMOD64 0
which is correct.
This makes the produced file unusable (at least with musl c-library). After
consulting with Rich Felker, the conclusion was that the relocation on i386
should be similar to what it is on x86_64, against 0 not indirect via the
section symbol.
Ignoring the 'SECTION' symbol and assuming at as self-reference on musl dynamic
linker is a workaround. But generating such a relocation sounds like a gold
bug.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
