On Mon, Mar 10, 2025 at 10:04 AM Fangrui Song <i...@maskray.me> wrote:
> I am intrigued by the problem but I have trouble understanding the > description. What behavior does this patch change? > > > riscv64-unknown-linux-gnu-gcc test.c > -Wl,--unresolved-symbols=ignore-in-object-files > > There is no -nostdlib, therefore I assume that this command creates a > dynamically linked executable (both -fpie -pie and -fno-pie -no-pie > are possible, depending on how users configure the GCC). > Oops, that's true. I think the original problem is for -no-pie. > I've tested a few cases but do not observe a behavior difference (in > terms of whether `foo` is in .dynsym and whether there is a JUMP_SLOT > relocation). > > ld-new --unresolved-symbols=ignore-in-object-files -o a a.o b.so > ld-new --unresolved-symbols=ignore-in-object-files -o a a.o > % cat a.s .text .weak c .globl _start _start: call a call b call c % cat b.s .globl b b: nop % riscv64-unknown-linux-gnu-as a.s -o a.o % riscv64-unknown-linux-gnu-as b.s -o b.o % riscv64-unknown-linux-gnu-ld -shared b.o -o b.so % riscv64-unknown-linux-gnu-ld -unresolved-symbols=ignore-in-object-files a.o b.o % riscv64-unknown-linux-gnu-objdump -d a.out ... Disassembly of section .text: 00000000000100b0 <_start>: 100b0: ffff0097 auipc ra,0xffff0 100b4: f50080e7 jalr -176(ra) # 0 <_start-0x100b0> 100b8: 00c000ef jal 100c4 <b> 100bc: 00000097 auipc ra,0x0 100c0: 000000e7 jalr zero # 0 <_start-0x100b0> 00000000000100c4 <b>: 100c4: 00000013 nop % riscv64-unknown-linux-gnu-ld -unresolved-symbols=ignore-in-object-files a.o b.so % riscv64-unknown-linux-gnu-objdump -d a.out ... Disassembly of section .plt: ... 0000000000010330 <b@plt>: 10330: 00002e17 auipc t3,0x2 10334: cd0e3e03 ld t3,-816(t3) # 12000 <b> 10338: 000e0367 jalr t1,t3 1033c: 00000013 nop 0000000000010340 <c@plt>: 10340: 00002e17 auipc t3,0x2 10344: cc8e3e03 ld t3,-824(t3) # 12008 <c> 10348: 000e0367 jalr t1,t3 1034c: 00000013 nop 0000000000010350 <a@plt>: 10350: 00002e17 auipc t3,0x2 10354: cc0e3e03 ld t3,-832(t3) # 12010 <a> 10358: 000e0367 jalr t1,t3 1035c: 00000013 nop Disassembly of section .text: 0000000000010360 <_start>: 10360: ff1ff0ef jal 10350 <a@plt> 10364: fcdff0ef jal 10330 <b@plt> 10368: fd9ff0ef jal 10340 <c@plt> But before this patch, all undefined weak and non-weak symbols will be forced to zero, % riscv64-unknown-linux-gnu-ld-old -unresolved-symbols=ignore-in-object-files a.o b.so % riscv64-unknown-linux-gnu-objdump -d a.out ... Disassembly of section .plt: ... 0000000000010330 <b@plt>: 10330: 00002e17 auipc t3,0x2 10334: cd0e3e03 ld t3,-816(t3) # 12000 <b> 10338: 000e0367 jalr t1,t3 1033c: 00000013 nop 0000000000010340 <c@plt>: 10340: 00002e17 auipc t3,0x2 10344: cc8e3e03 ld t3,-824(t3) # 12008 <c> 10348: 000e0367 jalr t1,t3 1034c: 00000013 nop 0000000000010350 <a@plt>: 10350: 00002e17 auipc t3,0x2 10354: cc0e3e03 ld t3,-832(t3) # 12010 <a> 10358: 000e0367 jalr t1,t3 1035c: 00000013 nop Disassembly of section .text: 0000000000010360 <_start>: 10360: ffff0097 auipc ra,0xffff0 10364: ca0080e7 jalr -864(ra) # 0 <_PROCEDURE_LINKAGE_TABLE_-0x10310> 10368: fc9ff0ef jal 10330 <b@plt> 1036c: 00000097 auipc ra,0x0 10370: 000000e7 jalr zero # 0 <_PROCEDURE_LINKAGE_TABLE_-0x10310> (lld has a quite simple model where undefined non-weak and undefined > weak symbols are handled in a unified way. > A symbol is preemptible if: > > * -shared or at least one input file is DSO, and > * the symbol is undefined or exported (to .dynsym due to > --export-dynamic/--dynamic-list/referenced by DSO/etc), and > * other conditions that the symbol is preemptible > > Then, a preemptible symbol might need a PLT and associated JUMP_SLOT > relocation.) > Yeah I think now the behavior is more similar to lld. Well, except the special handling for a call to undefined weak function, according to this page, https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/126 I suddenly feel like we should also apply this special handling to the calls which jump to an undefined non-weak function... Thanks Nelson
