Load-time relocation

[blm768]

I'm planning on starting my own OS project, and I'm looking at executable formats. I might end up making my own so I can use load-time relocation instead of position-independent code because it feels like a better solution to me, but I'm wondering why no major, modern OS seems to use this method. Is there some practical reason, or is it just how things ended up?

[NickJohnson]

If you use PIC, the same pages of memory containing the shared library code can be mapped in different processes in diffferent places. With relocations, you'd have to make a copy of the shared library every time you need to do a relocation, which can use more memory and adds complexity. Normally, you don't _need_ to do that many relocations, but if you want to use modern security features like ASLR, relocations make things as bad as or worse than static linking from a memory usage standpoint. PIC used to be pretty expensive on the 32-bit x86, but with instruction-pointer-relative addressing on the x86_64, there really isn't much of a disadvantage.

[blm768]

Good point. Since I don't plan on doing 32-bit x86 support anyway, I guess I'll just use PIC. I'm not sure about the executable format, though. ELF isn't too bad, but it feels a bit overcomplicated to me. Compounding the issue is that I'd like to write my own compiler framework too (yes, I know how how hard that is ), so I'd have to make it support ELF as well. Of course, if I want the compiler to work on other platforms, I'll need it to support ELF anyway...

[turdus]

Sometimes load-time relocation is the only reasonable option, but if you face such a situation, you should use jumptables. With a table you only have to relocate addresses in an array instead of immediates in code, which is a hell lot faster.
Jumptables widely used for referencing external library entry points (in which case each thread should have it's own copy of the table, and share PIC part of the library).
Also note that it's possible to reference data that way, it's rarely implemented. That would be very inefficient, as each memory access would require and extra memory access to get the value of the pointer first. Instead most use OS use register (rsp or rbp) relative addresses for variables.

[Owen]

Good point. Since I don't plan on doing 32-bit x86 support anyway, I guess I'll just use PIC. I'm not sure about the executable format, though. ELF isn't too bad, but it feels a bit overcomplicated to me. Compounding the issue is that I'd like to write my own compiler framework too (yes, I know how how hard that is ), so I'd have to make it support ELF as well. Of course, if I want the compiler to work on other platforms, I'll need it to support ELF anyway...

You think ELF is complex, try PE or OMF...

[qw]

... load-time relocation ... I'm wondering why no major, modern OS seems to use this method.

Doesn't Windows use load-time relocation, or am I misunderstanding the concept?

[blm768]

Sometimes load-time relocation is the only reasonable option, but if you face such a situation, you should use jumptables. With a table you only have to relocate addresses in an array instead of immediates in code, which is a hell lot faster.
Jumptables widely used for referencing external library entry points (in which case each thread should have it's own copy of the table, and share PIC part of the library).
Also note that it's possible to reference data that way, it's rarely implemented. That would be very inefficient, as each memory access would require and extra memory access to get the value of the pointer first. Instead most use OS use register (rsp or rbp) relative addresses for variables.

Is the reason for using jump tables for functions (rather than register-relative addressing) mainly to facilitate dynamically loading libraries during execution?

[NickJohnson]

... load-time relocation ... I'm wondering why no major, modern OS seems to use this method.

Doesn't Windows use load-time relocation, or am I misunderstanding the concept?

Windows does use load-time relocation, which is (one of multiple reasons) why it's ASLR implementation is horribly broken. The locations of libraries are randomized at boot time, instead of per process execution, so their locations can be easily leaked.

Anyway, ELF with PIC is significantly easier to implement than relocation, at a minor performance hit. I would strongly recommend using it. The ELF format is easy to load but also quite easy to embed additional data into if you need extensions.

[blm768]

Another quick question: does x86_64 support full 64-bit displacements on RIP-relative addressing? I'm having trouble finding docs on it.

[NickJohnson]

I think the x86_64 only supports 32 bit signed offsets for RIP-relative addressing. There's no issue using PIC with this restriction, of course, as long as each of your shared libraries is less than 2 GB in size.

[qw]

... load-time relocation ... I'm wondering why no major, modern OS seems to use this method.

Doesn't Windows use load-time relocation, or am I misunderstanding the concept?

Windows does use load-time relocation

So the conclusion is that Windows is not a major, modern OS.

[blm768]

So the conclusion is that Windows is not a major, modern OS.

Major? Yes. Modern? Only partially . I imagine that, like much software of its antiquity, it has plenty of old code.
Besides, it only "seemed" like no "major, modern" OS used link time relocation. With only a quick glance, that's indeed how it looks.

[Combuster]

And now you're mixing link-time and load-time relocation

The linker works by patching addresses in the input object files to match their relative positions. So pretty much every OS out there uses that form of "relocating".

[blm768]

And now you're mixing link-time and load-time relocation

Sorry; I was getting pretty tired when I wrote that. I _meant_ "load-time." I should cut back on the late-night OS development .