[PATCH] D63076: [ELF][RISCV] Support PLT, GOT, copy and relative relocations

[James Clarke via Phabricator via llvm-commits]

jrtc27 added inline comments.


================
Comment at: test/ELF/riscv-plt.s:72
+  call foo
+  call bar
+  call bar at plt
----------------
MaskRay wrote:
> jrtc27 wrote:
> > jrtc27 wrote:
> > > MaskRay wrote:
> > > > jrtc27 wrote:
> > > > > This should never use a PLT stub.
> > > > > This should never use a PLT stub.
> > > > 
> > > > Which function should not use a PLT stub? I think the behavior is consistent with ld.bfd, foo doesn't get a PLT but weak and bar get PLT stubs.
> > > Yes, and I'm 99% sure that's an unintended bug. If you delete the `call foo at plt`, then the `call bar` *doesn't* use a PLT stub.
> > I mean delete `call bar at plt`, of course...
> > Yes, and I'm 99% sure that's an unintended bug. If you delete the call bar at plt, then the call bar *doesn't* use a PLT stub.
> 
> I think you misread it..
> 
> bar at plt will be created, even if I delete `call bar at plt`. The behavior is consistent with ld.bfd.
> 
> Because bar is not local, a PLT has to be created.
No, the whole point is that by *not* adding `@plt` you forcefully bypass the PLT and don't allow bar to be preempted in this instance:

```
burn:snippets jrtc4% cat call-plt.s
.global test, foo, bar, baz

test:
    call foo
    call bar
    call bar at plt
    call baz at plt
burn:snippets jrtc4% riscv64-linux-gnu-gcc -o call-plt-pic.so -shared -fPIC call-plt.s -nostdlib
burn:snippets jrtc4% riscv64-linux-gnu-objdump -d call-plt-pic.so                               

call-plt-pic.so:     file format elf64-littleriscv


Disassembly of section .plt:

00000000000002f0 <.plt>:
 2f0:   00002397            auipc   t2,0x2
 2f4:   41c30333            sub t1,t1,t3
 2f8:   d103be03            ld  t3,-752(t2) # 2000 <.got>
 2fc:   fd430313            addi    t1,t1,-44
 300:   d1038293            addi    t0,t2,-752
 304:   00135313            srli    t1,t1,0x1
 308:   0082b283            ld  t0,8(t0)
 30c:   000e0067            jr  t3

0000000000000310 <baz at plt>:
 310:   00002e17            auipc   t3,0x2
 314:   d00e3e03            ld  t3,-768(t3) # 2010 <baz>
 318:   000e0367            jalr    t1,t3
 31c:   00000013            nop

0000000000000320 <bar at plt>:
 320:   00002e17            auipc   t3,0x2
 324:   cf8e3e03            ld  t3,-776(t3) # 2018 <bar>
 328:   000e0367            jalr    t1,t3
 32c:   00000013            nop

Disassembly of section .text:

0000000000000330 <test>:
 330:   00000097            auipc   ra,0x0
 334:   cd0080e7            jalr    -816(ra) # 0 <_PROCEDURE_LINKAGE_TABLE_-0x2f0>
 338:   fe9ff0ef            jal ra,320 <bar at plt>
 33c:   fe5ff0ef            jal ra,320 <bar at plt>
 340:   fd1ff0ef            jal ra,310 <baz at plt>
```

`foo` and `baz` behave as expected, with the former not using a PLT stub but the latter using a PLT stub (based on whether or not they were suffixed with `@plt`). However, *both* calls to `bar` end up using a PLT stub, despite only one of them having a `@plt` suffix. This is the BFD bug I was talking about.


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63076/new/

https://reviews.llvm.org/D63076