Bug 25500 - [powerpc] R_PPC_REL16_LO/R_PPC64_REL16_LO referencing a preemptible symbol should be rejected
Summary: [powerpc] R_PPC_REL16_LO/R_PPC64_REL16_LO referencing a preemptible symbol sh...
Status: NEW
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.35
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2020-02-04 05:55 UTC by Fangrui Song
Modified: 2020-02-04 09:37 UTC (History)
1 user (show)

See Also:
Target: powerpc*
Last reconfirmed: 2020-02-04 00:00:00


Note You need to log in before you can comment on or make changes to this bug.
Description Fangrui Song 2020-02-04 05:55:52 UTC
x86-64 (and many other archs)
cat > b.s <<e
.byte 0xe8
.long foo - . - 4

.section .text.foo,"ax",@progbits
.globl foo

as b.s -o b.o
ld.bfd b.o -shared # relocation R_X86_64_PC32 against symbol `foo' can not be used when making a shared object;  recompile with -fPIC

cat > a.s <<e
bcl 20,31,.+4
mflr 9
addi 9,9, (__kernel_datapage_offset - (.-4))@l

.section .text.foo,"ax",@progbits
.globl __kernel_datapage_offset

powerpc-linux-gnu-as a.s -o a.o
powerpc-linux-gnu-ld -shared a.o  # no error
powerpc64le-linux-gnu-as a.s -o a.o
powerpc64le-linux-gnu-ld -shared a.o  # no error

This is incorrect. STB_DEFAULT STV_DEFAULT __kernel_datapage_offset is preemptible in a shared object. If __kernel_datapage_offset binds to another component at runtime, the patched instruction will be wrong.
Comment 1 Alan Modra 2020-02-04 09:37:06 UTC
Many relocations should not use global symbols in shared libraries, but there is a lot of powerpc assembly out there that works well enough in the way it is used. I'm not inclined to break the powerpc/powerpc64 linux kernel without good reason..

Incidentally, using @l on a sequence that doesn't also have an instruction with @h or @ha is asking for trouble too: Relocation overflow won't be reported.