OSDev.org

klange wrote:

alexfru wrote:So, it looks like you're loading object files, not executable ones?

Yes, you'll find that my relocatable object loader loads relocatable objects. There is an executable loader in the function below that, though. There's also a dynamic linker but that is in userspace...

alexfru wrote:Do I understand it correctly that a proper ELF executable that can be loaded anywhere (because of ASLR or lack of page translation) needs to have a whole bunch of extra sections for the dynamic loader, even where a simple object file would suffice?

Don't confuse position independence with dynamic executables: you can have one, the other, both, or neither.

klange wrote:Time for some rambling:

Object files can represent any sort of code: executable, library; static, dynamic; position-independent or not... But regardless of what's in them, you absolutely need a linker to turn them into a final product - they are only an intermediary format. Object files consist only of sections, and lack the program headers found in executables and shared objects.

klange wrote:On most architectures, position-independent executables and libraries can actually be built statically and without any extra sections through the use of "thunks" and native IP-relative addressing schemes. On x86-32 these were notably slower at runtime than patched up absolute code, which was a very good reason to pick relocatable objects for device drivers. x86-64 and various other architectures don't suffer from the same speed impact, with x86-64 in particular introducing RIP-relative instructions.

The main benefit behind position-independent code, even when it does involve relocations - which it will in the case of a dynamic library that references other libraries as relocations are what fills in the addresses of runtime-resolved symbols - is that the relocations are moved away from the code so that the number of pages that need to be modified per-process is minimized (usually through a global offset table). This means you can "load once, run anywhere" in the sense that you can have a shared library in physical memory once and then map it into userspace memory layouts for every process that references that library, and they'll only need their own private copies of the small set of pages with relocations.

alexfru wrote:Can I just slap relocations onto an ELF executable?

alexfru wrote:But what's the equivalent for this in the ELF executables? How do I express it? Do I make an ELF file that has both relocations and program segments?

alexfru wrote: Do I understand it correctly that a proper ELF executable that can be loaded anywhere (because of ASLR or lack of page translation) needs to have a whole bunch of extra sections for the dynamic loader, even where a simple object file would suffice?

zaval wrote:

alexfru wrote: Do I understand it correctly that a proper ELF executable that can be loaded anywhere (because of ASLR or lack of page translation) needs to have a whole bunch of extra sections for the dynamic loader, even where a simple object file would suffice?

it seems, that you understood it right. because how else one can make an ELF executable both non-PIC and relocatable? only by storing all base relocations (in terms of PE) in it. how to do that for the format, that has no notion of the image base and direct provision for storing the base relocations? you would need to provide the "dynamic" segment, pointing to the .dynamic section, which in turn would point to relocations. as if this were a "dynamic" object (shared or executable, in terms of ELF). this is basically those "extras" of the dynamic linker (in terms of ELF), you mentioned. and this is probably what PIE option creates. but I'm not sure, since I myself only learn this clumsy thing.

but with an object file (relocatable object, in terms of ELF), you don't have to have all that, just plain relocations, lying in some section (what?) of course, if all the object relocations are resolved and removed and only base relocations (in terms of PE) are left. because otherwise, that would be a lot of litter, as pointed out above.

in both cases, however, trying to insert there importing/exporting somehow, constantly fails (at least, how I see it), without resorting to that horrendous .got, .plt, .gotplt PIC thing. of course, a compiler writer might reproduce IAT semantics, given he creates a compiler for the environment, that would understand it. after all, the main problem is the compiler not understanding, that an imported function should be called through an indirect call (using a format provided special function table), being resolved at the load time or even later.

nexos wrote:

zaval wrote:(but if I could choose, I'd definitely go with PE, - it's to the OP).

PE is much better the ELF in some ways (mainly dynamic linking). Loading an ELF, however, is very simple, so hence they both have there advantages and disadvantages.
@bloodline - For one thing, if you build an ELF app as position independent in GCC, then you can relocate it just like a simple object file. Loading only object files will prevent growth of your OS, hence I recommend looking into PIC (position independent code). Also, if you aren't making a Unix clone, you could trying looking into PE or Mach-O. PE is probably the simplest out of the bunch. I know nothing about Mach-O, so there is no help from me there TL;DR Don't just look at ELF because it is the de facto standard, there are other good formats out there you should check out

klange wrote:

alexfru wrote:Can I just slap relocations onto an ELF executable?

Sure.

alexfru wrote:But what's the equivalent for this in the ELF executables? How do I express it? Do I make an ELF file that has both relocations and program segments?

Yes?

Make a dynamic executable, slap it full of the architecture's most basic relocation type (eg. R_X86_64_64) to shift everything to load address, and that's about it. You might have to mark it DYN rather than EXEC to get a loader to actually recognize that its base address is adjustable, check whatever PIE produces and do the same thing minus the PIC code.

bloodline wrote:Can some x86 expert see if this disassembly makes any sense?

Octocontrabass wrote:

bloodline wrote:Can some x86 expert see if this disassembly makes any sense?

I see a couple of MOV instructions that are encoded with opcode 0xC7 instead of the shorter opcode 0xB8. It looks like the linker is applying an optimization that's not supposed to apply to position-independent code.

Doesn't -static-pie require you to link with startup code that will fix the relocations?

Octocontrabass wrote:

bloodline wrote:Can some x86 expert see if this disassembly makes any sense?

I see a couple of MOV instructions that are encoded with opcode 0xC7 instead of the shorter opcode 0xB8. It looks like the linker is applying an optimization that's not supposed to apply to position-independent code.

Doesn't -static-pie require you to link with startup code that will fix the relocations?

mov $0x4,%edx
mov -0x4(%eax),%eax
add %eax,%eax
mov %eax,(%edx)

bloodline wrote:

Code: Select all

mov $0x4,%edx
mov -0x4(%eax),%eax
add %eax,%eax
mov %eax,(%edx)

Octocontrabass wrote:

bloodline wrote:

Code: Select all

mov $0x4,%edx
mov -0x4(%eax),%eax
add %eax,%eax
mov %eax,(%edx)

Is that first MOV encoded using opcode 0xC7 instead of the shorter opcode 0xBA? If it is, the linker patched that instruction.

Anyway, trying to guess where relocations should be applied isn't going to fix the actual problem, which is a lack of relocations in your binary.

Unfortunately I have no suggestions for how to fix it...