<div dir="ltr">I have been unsuccessful at modifying the amd64 codegen, but I know what the assembly should look like now. <br><br>For position dependent code (PDC) the current codegen does everything correct. For position independent code (PIC), it matters whether or not the object being accessed is linked into the same .so or whether it is provided by another library. This distinction doesn't matter in the PDC case.<br>
<br>PDC Address: movq $name, %rax<br>PDC Function Call: call name<br>PDC Data Access: movq name, %rax<br><br>PIC Internal Address: leaq name(%rip),%rax<br>PIC Internal Function Call: call name<br>PIC Internal Data Access: movq name(%rip),%rax<br>
<br>PIC External Address: movq name@GOTPCREL(%rip),%rax<br>PIC External Function Call: call name@PLT<br>PIC External Data Access: movq name@GOTPCREL(%rip),%rax; movq (%rax),%rax<br><br>Interestingly, gcc uses movq name(%rip),%eax even for PDC data access. Perhaps it's faster?<br>
<br>So the amd64 codegen should use the PIC Internal instructions when compiled to a library.<br><br>Since all system calls needed by the basis library are made via the runtime, which is linked with the amd64 codegen output, a program not using user FFI will never need the PIC External instructions. If the user uses the FFI to import his own functions and variables, there should also be no problem because those are linked together into the output library.<br>
<br>The only case were PIC External would be needed is if the user writes an SML-only wrapper for an existing library and an SML project using this wrapper gets compiled into a library itself. If the wrapper proxied all it's calls via C like the basis, there would again be no problem.<br>
<br>To solve this one corner case, it would suffice to add an "external" keyword to _import.<br><br><br>PS. It's a shame that the x86/amd64 codegens are so difficult to understand (lack of documentation, too much indirection, and no way to inspect intermediate results). This has prevented me from getting the win64 calling convention to work and also from making the simple instruction substitution I've outlined here. I don't know what to do about this problem, but I do think it is a barrier to contributing to MLton.<br>
</div>