Relocatable flat binaries

[scgtrp]

I'm really trying to avoid implementing ELF as it's really complex, and the only feature I really need from it is relocation. Is there a way to get ld to generate a flat binary, but with a table of all the addresses used so I can relocate them? Or is there another relocatable format I can use that's simpler than ELF?

[cyr1x]

Position Independant Code probably works. Other formats would be a.out, coff, pe, ..

[scgtrp]

I considered PIC, but decided against it as this is for my kernel modules, which will eventually be able to do all kinds of cool stuff like call each other's functions. I don't want to slow it down too much by forcing it to go through a kernel function that replaces whatever the PIC base address register is, calls the function, then replaces the register's value again.

PE... ick. I'll take a look at a.out and COFF, but I really wanted to simplify it as much as possible by getting ld to just throw a relocation table on a flat binary.

[mathematician]

I considered PIC, but decided against it as this is for my kernel modules, which will eventually be able to do all kinds of cool stuff like call each other's functions. I don't want to slow it down too much by forcing it to go through a kernel function that replaces whatever the PIC base address register is, calls the function, then replaces the register's value again.

PE... ick. I'll take a look at a.out and COFF, but I really wanted to simplify it as much as possible by getting ld to just throw a relocation table on a flat binary.

You could try an old fashioned DOS exe, which isn't too bad. Alternatively, although I don't know what you have in mind, in 32 bit mode you could use segmentation to relocate your kernel until you get paging going.

[scgtrp]

You could try an old fashioned DOS exe, which isn't too bad.

They're relocatable? I thought they could always load at a fixed address since you were guaranteed to not be doing any multitasking.

Alternatively, although I don't know what you have in mind, in 32 bit mode you could use segmentation to relocate your kernel until you get paging going.

I don't plan on using paging; my kernel runs everything in a ring 0 virtual machine. I did think about segmentation but decided against it since switching segments causes way too much overhead.

[Dex]

You can write a simple program to split a COFF file into two files, the code/data etc and the other the relocatable info.
This mean you can have much small file format, but in a simple way.
If you want more info let me know.

[scgtrp]

You can write a simple program to split a COFF file into two files, the code/data etc and the other the relocatable info.
This mean you can have much small file format, but in a simple way.
If you want more info let me know.

It looks like, given a relocatable file test.o, it should be possible to do

Code: Select all

ld -Ttext=0 test.o -o test.bin --oformat=binary

and get it in flat binary form. One of the binutils tools (objdump, objcopy, maybe even ld with a fancy script?) should be able to extract the relocation information to another file, shouldn't it? I'm looking into that now.

Edit: Ooh, this looks useful...

Code: Select all

[mike: mike in ~/code/testing]$ readelf -r test.o

Relocation section '.rel.text' at offset 0x2d4 contains 1 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000009  00000702 R_386_PC32        00000000   foo

[mathematician]

You could try an old fashioned DOS exe, which isn't too bad.

They're relocatable? I thought they could always load at a fixed address since you were guaranteed to not be doing any multitasking.

No, you could stick them anywhere you liked. EXE files had a relocation table, and COM programs didn't even need that. Although there was no multi-tasking, unless you fixed it up for yourself, there could have memory resident programs installed. A common use for them was to modify the operating system - or you could press some "hot key", and a utility program of some kind would pop up.

Way back when, CP/M programs could only be loaded at a fixed address.

[skyking]

I'm really trying to avoid implementing ELF as it's really complex, and the only feature I really need from it is relocation. Is there a way to get ld to generate a flat binary, but with a table of all the addresses used so I can relocate them? Or is there another relocatable format I can use that's simpler than ELF?

Maybe the problem is that you expect the solution may be simplier than it can be? What you seem to need is relocatable executable, which must include some complexity. You will need some kind of file header and relocation table. ELF is not much more complex than that (given that you don't have to support everything in the spec - since you control what kind of features you use in the output).

Also to consider is the possibility to generate the executable. If your linker does not output format X you have to either convert from a supported format to format X (which is not less complex than implement a loader that reads the linker output format), or write a linker that produces output of the format X (which is not less complex than complex than implement a loader that reads the linker input format). So you're stuck with the options of using either ELF or COFF (or well a.out) unless of course you have a very different linker than the rest of us, but I don't see either to be a lot less complex choice.

[Dex]

See here for info on how to fix your problem http://forum.osdev.org/viewtopic.php?f= ... 08#p157308

[pcmattman]

I'm really trying to avoid implementing ELF as it's really complex

I agree with skyking. It's not actually that difficult to load and execute an ELF binary, and it will make things far easier in the future when you reach things like shared objects.

The relocations you need for ELF are clearly specified in the specification, and it's quite straightforward to implement them if your API design is at least somewhat decent.