Linkers and architectures

Question

Why do we have linkers for different architectures? The linker service is for address resolution. So how does this relate to the instructions of the target architecture?

Answer 1

There are many, many reasons, and I cannot exhaustively list them all.

• Linkers need to do a lot more work when the architecture does not support position-independent code. In these cases, it is necessary to allow even jumps within functions.

• Linkers need to create architecture-specific headers, such as ELF or PE headers.

• Linkers need to include resources, data forks, or similar things on their supporting platforms.

• Linkers need to instantiate exported C ++ templates

• Linkers also need to deal with addresses that cannot yet be resolved. This may include system calls or dynamically loaded libraries.

• When linking a dynamic library, the linker needs to export more than one input function. Different architectures use different methods to indicate which functions should be exported.

• Linkers may need to insert actual call sequences if they cannot be determined at compile time. For example. for architectures that support two instruction sets, a “command set key” should be inserted whenever the caller and callee differ in the instruction set used.

• Linker optimization can be based on architecture-specific details. For example. if function calls within the 4 KB region are faster, it makes sense to put the interlocutor and the interlocutor close to each other.

• Embedding between object files can be performed, but this requires deleting the call setup, skip prolog, epilogue method and processing the return value. They are architecture-specific, so architects-specific linkers are required to recognize them.

Answer 2

Different architectures have different address formats in their instructions, which the linker must know in order to manage them.

Relative addressing can lead to different instructions depending on the size of the relative address.

More complex schemes also exist, for example, for ARM.

This is usually described in addition to the linker format specification, for example, look at the documents associated with this Wikipedia article on ELF format .

Answer 3

To resolve addresses, the linker needs to at least know the finiteness and size of the addresses. Some architectures, such as real-mode x86, have more complex addressing schemes, some embed addresses in the instruction, so the linker may need to know the address or offset field.

Answer 4

Some linkers can be built to understand several architectures. For example, I use gnu ld, gdb, binutils and assemblers for my cross-compiler project http://ellcc.org . I have an assembler specific for every purpose, but linker, debugger and binutils all understand all processors. The supported processors are quite diverse: ARM, CellSPU, Mips, MSP430, Nios2, PIC16, PowerPC, PowerPC64, Sparc, X86, X86_64.

Answer 5

Some toolchains are designed in such a way that a huge part of optimizations is delayed until link time, when all information about the program is available. The advantages of embedding, continuous distribution, and many other traditional optimizations are most applicable to all binary, and not just to every object.