https://sourceware.org/bugzilla/show_bug.cgi?id=29655
Bug ID: 29655
Summary: s390x gas generates PC32DBL instead of PLT32DBL for
function call
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: rui314 at gmail dot com
Target Milestone: ---
gas 2.38 assembles the following assembly
larl %r1,printf
brasl %r1,printf
into the following object file:
Disassembly of section .text:
0000000000000000 <.text>:
0: c0 10 00 00 00 00 larl %r1,0x0
2: R_390_PC32DBL printf+0x2
6: c0 15 00 00 00 00 brasl %r1,0x6
8: R_390_PC32DBL printf+0x2
. As you can see, gas generates PC32DBL for both larl and brasl. PC32DBL seems
to be correct for larl because the instruction is to obtain the address of the
specified symbol. However, I think it's not correct for brasl because it's not
an address-taking instruction but a function call instruction.
For other targets, we generally distinguish address-taking instructions from
function-call instructions. For the former, gas generates PC<SIZE> relocation
while it generates PLT<SIZE> relocation for the latter. Examples are
R_X86_64_PC32 and R_X86_64_PLT32. gas won't create PC32 relocation for the
x86-64 CALL instruction.
I noticed this issue when working on porting the mold linker to s390x. In mold,
we distinguish address-taking relocations (PC<SIZE> relocs) from
non-address-taking relocations (PLT<SIZE> relocs). We use the information to
decide whether we should create a canonical PLT or not.
It's a subtle difference, so most applications work fine even if the assembler
doesn't distinguish the two types of relocations, but there are a few
applications that depend on the difference. Qt5 is a notable example. So I
believe Qt5 apps won't work correctly on S390. Maybe it doesn't matter in
practice as people probably aren't running GUI apps on mainframes. But Qt5 is
just one example; it could cause other subtle portability issues for other
apps.
So, could make a change to gas so that it distinguishes R_390_PC32DBL and
R_390_PLT32DBL?
--
You are receiving this mail because:
You are on the CC list for the bug.
