R_RISCV_32 is not a dynamic relocation for RV64

[rui314]

Currently, https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc classifies R_RISCV_32 as a "both" (dynamic and static) relocation. But it's considered a dynamic relocation only on RV32. I think we should make it clear that fact in the spec.

[kito-cheng]

Yeah, glibc only handle R_RISCV_32 on RV32, and R_RISCV_32 is only used in debug info for RV64.

[rui314]

Yup. Likewise, R_RISCV_64 can be used as a dynamic relocation only on RV64.

[kito-cheng]

Yup. Likewise, R_RISCV_64 can be used as a dynamic relocation only on RV64.

I am also thinking about how we describe those relocations which refer to 32/64, and might only used in RV32 / RV64.

[rui314]

How about splitting the relocation into three tables for common, RV32 and RV64?

[kito-cheng]

I would like to defer fixing this after release, manipulate such complicated table on asciidoc is so painful...

[Nelson1225]

I also meet the similar problem recently, so I spend some time to see what's going on of this. Here is the behavior of aarch64 binutils,

$ cat tmp.s
.hidden h
.globl g
.4byte h
.8byte h
.4byte g
.8byte g

$ aarch64-linux-gnu-as tmp.s -o tmp.o
$ aarch64-linux-gnu-ld -shared --defsym g=0x100 --defsym h=0x200 tmp.o
$ aarch64-linux-gnu-objdump -d a.out
...
00000000000001e0 <.text>:
 1e0:   00000200        .word   0x00000200
 1e4:   00000200        .word   0x00000200
 1e8:   00000000        .word   0x00000000
 1ec:   00000100        .word   0x00000100
        ...
$ aarch64-linux-gnu-readelf -Wr a.out

Relocation section '.rela.dyn' at offset 0x1b0 contains 2 entries:
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
0000000000000000  0000000000000000 R_AARCH64_NONE                            0
00000000000001f0  0000000200000101 R_AARCH64_ABS64        0000000000000100 g + 0

$ aarch64-linux-gnu-readelf -Ws a.out
Symbol table '.dynsym' contains 3 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
...
     2: 0000000000000100     0 NOTYPE  GLOBAL DEFAULT  ABS g

Symbol table '.symtab' contains 17 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
...
    14: 0000000000000200     0 NOTYPE  LOCAL  DEFAULT  ABS h
...
    16: 0000000000000100     0 NOTYPE  GLOBAL DEFAULT  ABS g

If the symbol is ABS (absolute), then only the R_AARCH64_ABS64 with global ABS needs a dynamic relocation when building shared library; Otherwise, just resolved internally. The R_AARCH64_NONE is for ".8byte h", which is a local ABS symbol.

$ cat tmp.s
.globl g
g:
.4byte g
.8byte g
$ aarch64-linux-gnu-as tmp.s -o tmp.o
$ aarch64-linux-gnu-ld -shared tmp.o
.*tmp.o: relocation R_AARCH64_ABS32 against `g' can not be used when making a shared object

Considering that the symbol is address rather than ABS, R_AARCH64_ABS32 isn't allowed for 64 bits system, and the local symbol has the same limitation. Therefore, compared to RISC-V, maybe we should,

Under RV64	Static R_RISCV_32	Static R_RISCV_64
local ABS	without dynamic relocation	without dynamic relocation
local address	Report error	RELATIVE
global ABS	without dynamic relocation	R_RISCV_64 (RELATIVE when -Bsymbolic or -pie)
global address	Report error	R_RISCV_64 (RELATIVE when -Bsymbolic or -pie)

I have a patch to make GNU risc-v binutils has the same behavior as aarch64, so need your help to confirm if the above behavior is reasonable and acceptable in psabi and lld :- )

Thanks Nelson

[rui314]

@Nelson1225 This is a bit off-topic because that's an implementation detail and not a part of the psABI. But I think the correct tables are https://github.com/rui314/mold/blob/67eb3069b3e7c77632c3c015a3f1324b2bab87e9/elf/input-sections.cc#L234-L249 and https://github.com/rui314/mold/blob/67eb3069b3e7c77632c3c015a3f1324b2bab87e9/elf/input-sections.cc#L251-L267.