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