[Bug ld/24683] New: RISC-V call and callplt reloc handling

[wilson at gcc dot gnu.org]

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

            Bug ID: 24683
           Summary: RISC-V call and callplt reloc handling
           Product: binutils
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: wilson at gcc dot gnu.org
  Target Milestone: ---

Another one from the lld folks.

Given
.global test, foo, bar, baz
test:
    call foo
    call bar
    call bar@plt
    call baz@plt
and compiling it with
    gcc -o call-plt-pic.so -shared -fPIC call-plt.s -nostdlib
objdump shows the result is
00000000000002c0 <test>:
 2c0:   00000097                auipc   ra,0x0
 2c4:   d40080e7                jalr    -704(ra) # 0
<_PROCEDURE_LINKAGE_TABLE_-0x280>
 2c8:   fe9ff0ef                jal     ra,2b0 <bar@plt>
 2cc:   fe5ff0ef                jal     ra,2b0 <bar@plt>
 2d0:   fd1ff0ef                jal     ra,2a0 <baz@plt>

Two things to notice here.  The direct call to the undefined foo is branching
to nowhere.  That should probably be a linker error.  And both the direct and
plt calls to bar are going through the plt which looks odd and may be a bug. 
This probably depends on what the psABI says.

If I clean up the testcase a little to make more sense, and define the
functions that should be defined to get the right result
.global test, foo, bar, baz
foo:
        ret
bar:
        ret
baz:
        ret
test:
    call foo
    call bar
    call bar@plt
    call baz@plt
then I get
00000000000002d6 <test>:
 2d6:   ffbff0ef                jal     ra,2d0 <foo>
 2da:   fe7ff0ef                jal     ra,2c0 <bar@plt>
 2de:   fe3ff0ef                jal     ra,2c0 <bar@plt>
 2e2:   fcfff0ef                jal     ra,2b0 <baz@plt>

The call to foo is correct now, but the direct call to bar is still going
through the plt.

Experimenting on x86, I can't get a direct call unless I mark the function
protected visibility.  And if I do that, then both the direct call and plt call
become direct calls in the output, which makes sense for a protected visibility
function.  Which means I apparently can't have both direct and plt calls for
the same symbol (at least not without using an alias).  Unless maybe I missed
an x86 syntax for this, I haven't spent much time looking at this yet, just
recording info for later.

-- 
You are receiving this mail because:
You are on the CC list for the bug.