On Sun, Mar 9, 2025 at 7:59 PM Nelson Chu <nel...@rivosinc.com> wrote: > > > > 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.)
Thanks for the example! I see that the branch target is now more meaningful after the patch. > > 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
