[Bug gas/29655] New: s390x gas generates PC32DBL instead of PLT32DBL for function call

[rui314 at gmail dot com]

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.