bug-binutils
[Top][All Lists]
Advanced

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

[Bug ld/26936] [ld, PIE] ld drops relocation for .text.__x86.get_pc_thun


From: matz at suse dot de
Subject: [Bug ld/26936] [ld, PIE] ld drops relocation for .text.__x86.get_pc_thunk.bx
Date: Tue, 24 Nov 2020 17:17:23 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=26936

Michael Matz <matz at suse dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at suse dot de

--- Comment #14 from Michael Matz <matz at suse dot de> ---
So, it's a bit involved.  As far as I can determine it needs a linkonce section
(not just a comdat group!) and three input files.  Reproducer:

% cat crt.s
        .file   "crt.s"
        .section        .gnu.linkonce.t.__x86.get_pc_thunk.bx,"ax",@progbits
        .globl  __x86.get_pc_thunk.bx
        .hidden __x86.get_pc_thunk.bx
        .type   __x86.get_pc_thunk.bx, @function
__x86.get_pc_thunk.bx:
        .cfi_startproc
        movl    (%esp), %ebx
        ret
        .cfi_endproc

% cat split-1.s
        .file   "split-1.c"
        .text
.Ltext0:
        .globl _start
_start:
        .globl  main
        .type   main, @function
main:
        ret
        .size   main, .-main
        .section       
.text.__x86.get_pc_thunk.bx,"axG",@progbits,__x86.get_pc_thunk.bx,comdat
        .globl  __x86.get_pc_thunk.bx
        .hidden __x86.get_pc_thunk.bx
        .type   __x86.get_pc_thunk.bx, @function
__x86.get_pc_thunk.bx:
        .cfi_startproc
        movl    (%esp), %ebx
        ret
        .cfi_endproc

% cat morestack.S
 .section
.text.__x86.get_pc_thunk.bx,"axG",@progbits,__x86.get_pc_thunk.bx,comdat
 .globl __x86.get_pc_thunk.bx
 .hidden __x86.get_pc_thunk.bx
 .type __x86.get_pc_thunk.bx, @function
__x86.get_pc_thunk.bx:
 .cfi_startproc
 movl (%esp), %ebx
 ret
 .cfi_endproc
 .size __x86.get_pc_thunk.bx, . - __x86.get_pc_thunk.bx

Note how crt.s uses a traditional linkonce section while the others use comdat
groups.  Also note that all three define the symbol in question.  Now, compile
with -g and observe relocations and lineinfo:

% gcc -m32 -g -c crt.s split-1.s morestack.S
% readelf -W -wl -r morestack.o
...
Relocation section '.rel.debug_line' at offset 0x238 contains 1 entry:
 Offset     Info    Type            Sym.Value  Sym. Name
0000002f  00000401 R_386_32               00000000  
.text.__x86.get_pc_thunk.bx
...
 Line Number Statements:
  [0x0000002c]  Extended opcode 2: set Address to 0x0
  [0x00000033]  Advance Line by 9 to 10

Observe how the line number address should be relocated to the final address of
the .text.__x86.get_pc_thunk.bx symbol.  Now link and observe line number info
again:

% /matz/git/binutils/dev/ld/ld-new -m elf_i386 crt.o split-1.o morestack.o
% readelf -W -s -wl -r a.out
...
    12: 08049000     0 FUNC    GLOBAL HIDDEN     1 __x86.get_pc_thunk.bx
...
 The File Name Table (offset 0x97):
  Entry Dir     Time    Size    Name
  1     0       0       0       morestack.S

 Line Number Statements:
  [0x000000a7]  Extended opcode 2: set Address to 0x0
  [0x000000ae]  Advance Line by 9 to 10

Address is still zero, the relocation wasn't applied.  (PIE doesn't seem to
matter in this reduced case anymore).

Note that the equivalent relocation from split-1.s _is_ applied:

...
 The File Name Table (offset 0x50):
  Entry Dir     Time    Size    Name
  1     0       0       0       split-1.s

 Line Number Statements:
...
  [0x0000006b]  Extended opcode 2: set Address to 0x8049000
  [0x00000072]  Advance Line by 19 to 20

It's also resolved in the line number section of crt.s.  If I use a comdat
group in crt.s (not a link once section) the problem goes away.  If I remove
split-1.o
from the link (and accept the warning about missing _start), the relocation in
morestack.o is correctly resolved.

So, there's definitely something fishy with the discarded sections and
relocations referring to them.

-- 
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]