bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gold/17699] New: incorrect R_386_TLS_DTPMOD32 relocation


From: timo.teras at iki dot fi
Subject: [Bug gold/17699] New: incorrect R_386_TLS_DTPMOD32 relocation
Date: Thu, 11 Dec 2014 17:19:11 +0000

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]