Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>There are many, many reasons, and I cannot exhaustively list all of them.</p> <ul> <li><p>Linkers need to do a whole lot more work when an architecture does not support position-independent code. In those cases, even jumps <em>within</em> functions need to be resolved.</p></li> <li><p>Linkers need to create architecture-specific headers, such as ELF or PE headers.</p></li> <li><p>Linkers need to include resources, data forks or similar things on platforms that support them</p></li> <li><p>Linkers need to instantiate exported C++ templates</p></li> <li><p>Linkers also need to deal with addresses that cannot be resolved yet. This can include system calls, or dynamically loaded libraries.</p></li> <li><p>When linking a dynamic library, a linker needs to export more than a single entry function. Different architectures uuse different methods to indicate which functions are to be exported</p></li> <li><p>Linkers may need to insert the actual call sequences if they cannot be determined at compile time. E.g. for architectures that support two instruction sets, an "instruction set switch" needs to be inserted whenever the caller and callee differ in instruction set used.</p></li> <li><p>Linker optimizations can be based on architecture-dependent details. E.g. if function calls within a 4KB region are faster, it makes sense to put caller and callee close together.</p></li> <li><p>Inlining across object files can be done, but requires removal of the call setup, callee prolog, callee epilog and return value handling. Those are architecture-specific, so just recognizing them already takes an architecure-specific linker.</p></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload