Re: Baby X is bor nagain

On 28/06/2024 04:30, Kaz Kylheku wrote:

On 2024-06-27, bart <bc@freeuk.com> wrote:

For most, PIC isn't a necessity.

 Only because they use a virtual memory operating system which allows
every executable to be mapped to the same fixed address in its own
address space.

PIC never seemed to be a requirement during the 1980s and half the 90s. But then OSes only ran one program a time.
And when virtual addressing came along, and multiple programs could co-exist at the same address, PIC wasn't really needed either.

 If you designed your personal OS, which would be the case?
 [ ] Programs must be PIC
 [ ] Programs needn't be PIC

With or without virtual addressing?
On x64, there are several aspects to this:
* Code that runs within the low 2GB (4GB is troublesome)
* Code that runs above 2GB, so that 32-bit fields (often signed so that only 31 bits are usable) that refer to absolute addresses of code or data will need 33 bits or more
* Dynamically linked /shared/ libraries, which need to have base-relocation tables (since you can't have multiple libraries all at the same address within the host process's virtual space), but which are not necessarily relocated above 2GB
* True PIC that requires special compiler support (to avoid generating address modes that involve registers plus absolute 32-bit address offsets). RIP-relative address modes, when there are no registers, can be done with instruction encoding outside of the compiler
It's all rather messy.
I can generate true PIC if necessary (for OBJ files that might be linked with ld, or DLLs that /might/ be relocated above 2GB).
But usually I generate code to load within the first 2GB.