2 ms·

Position-Independent Executables (and ASLR) were used by AmigaOS back in 1985. It had to, since the Amiga lacked an MMU, and had very little memory, so anything

Position-Independent Executables (and ASLR) were used by AmigaOS back in 1985. It had to, since the Amiga lacked an MMU, and had very little memory, so anything that was loaded had to be placed at whatever ram was available. It didn't need the executable to end up in a single block either, every individual section could end up in a different location. Compilers produced large numbers of sections to facilitate this process.

amiga386 2y ago
That's not what's meant by PIE though. It means the code can appear at any address and still be valid. Amigas could, of course, have position-independent code. Use BSR and BRA rather than JSR and JMP; use LEA label(pc),A0 / MOVE.L (A0),D0 instead of MOVE.L label,D0 .. but the limits for PC-relative addressing are +/- 32k so you need to get creative to reach code or data further than that. More commonly, Amiga executables had relocs, a list of fixups to apply. The code on disk in each hunk was written as if all hunks were loaded at address 0. There was then a list of relocations at the end of each hunk, saying what offsets in that hunk need the base address of another hunk (including themselves) added there, to fixup the absolute address reference. This is relocatable code, but not position independent code. If I used an MMU to make that relocated code appear at another address, all its absolute addressing would be wrong at that new address. Position-independent code can be shared by multiple proceeses, and appear anywhere in their address space, while only existing once in memory
- Joker_vD 2y ago
  Well, PIC, as it commonly is done nowadays (via PC-relative addressing), requires the static/global data it references to be postioned at very specific offset from it. Which prohibits one not only from e.g. putting in 16 GiB away (why would you actually want this?) but also from having unduly large code modules — x64 only provides ±2GiB for PC-relative addressing so you'd have to use some sort of indirection scheme anyhow.
- IcePic 2y ago
  Well, resident programs (actual Pure residents in AmigaOS) would be like PIE, though that came a bit later, and gave the same effect, several programs could run the same code with different set of registers, and all data was pointed to by registers and no globals.
  - amiga386 2y ago
    It's still not position independent code (i.e. no absolute addressing, zero relocs), but pure residents are of course reentrant, so their code can be run in many processes' contexts at the same time, by virtue of not using any global state, instead using the process's stack, or have heap allocations that are passed in/out. The difference is that, with position-independent code, it can be loaded once, no relocations needed, and the same pages of code can be mapped into hundreds of processes' address spaces, each at a random location. Doing it like resident Amiga programs would mean loading to a specific address (even if random), and then it'd have to remain at that address across all processes, which makes it difficult to have different combinations of shared objects in the address space.

amiga386 2y ago

That's not what's meant by PIE though. It means the code can appear at any address and still be valid. Amigas could, of course, have position-independent code. Use BSR and BRA rather than JSR and JMP; use LEA label(pc),A0 / MOVE.L (A0),D0 instead of MOVE.L label,D0 .. but the limits for PC-relative addressing are +/- 32k so you need to get creative to reach code or data further than that. More commonly, Amiga executables had relocs, a list of fixups to apply. The code on disk in each hunk was written as if all hunks were loaded at address 0. There was then a list of relocations at the end of each hunk, saying what offsets in that hunk need the base address of another hunk (including themselves) added there, to fixup the absolute address reference. This is relocatable code, but not position independent code. If I used an MMU to make that relocated code appear at another address, all its absolute addressing would be wrong at that new address. Position-independent code can be shared by multiple proceeses, and appear anywhere in their address space, while only existing once in memory

Joker_vD 2y ago
Well, PIC, as it commonly is done nowadays (via PC-relative addressing), requires the static/global data it references to be postioned at very specific offset from it. Which prohibits one not only from e.g. putting in 16 GiB away (why would you actually want this?) but also from having unduly large code modules — x64 only provides ±2GiB for PC-relative addressing so you'd have to use some sort of indirection scheme anyhow.
IcePic 2y ago
Well, resident programs (actual Pure residents in AmigaOS) would be like PIE, though that came a bit later, and gave the same effect, several programs could run the same code with different set of registers, and all data was pointed to by registers and no globals.
- amiga386 2y ago
  It's still not position independent code (i.e. no absolute addressing, zero relocs), but pure residents are of course reentrant, so their code can be run in many processes' contexts at the same time, by virtue of not using any global state, instead using the process's stack, or have heap allocations that are passed in/out. The difference is that, with position-independent code, it can be loaded once, no relocations needed, and the same pages of code can be mapped into hundreds of processes' address spaces, each at a random location. Doing it like resident Amiga programs would mean loading to a specific address (even if random), and then it'd have to remain at that address across all processes, which makes it difficult to have different combinations of shared objects in the address space.