Has anyone gotten ELF user programs to run?

[kernel64]

I'm curious to know if anyone's gotten that far in their kernel development that they can actually run user programs, and specifically, if the kernel runs ELF programs.

I have a good book called Linkers and Loaders by John Levine, and I'm finding that while it's enlightening, I'm still left with questions. (Levine hasn't finished writing all the project code for the book's chapters; I'll get around to it, but first...)

Programs need to be relocated at run time if they aren't put at their declared link address, unless it is possible to do something with the virtual memory space so that the link time and load address is faked in the VM software (I haven't gotten that far yet in my study, I'm still working on mono-tasking without a VM manager!) I'm talking about comparitively simple statically linked programs. The relocation sections in the ELF binary tell the OS what needs to be relocated. Is it really "that simple?" Any gotchas here?

What about shared libraries and binaries linked with -FPIC or -DPIC? What's the difference between this and code that isn't using PIC, as far as the kernel's program loader/relocater code goes?

I'm wondering if it's worth starting with the simpler a.out format for binaries first, getting that working, then adding support for ELF binaries, and finally for the works, PIC and shared libraries and all.

Thanks...

[kernel64]

Just a quick note: this kind of information is seriously lacking in OS FAQs and other tutorial documents because arguably it is the most important topic in OS development: making programs run!

The best resource so far for the beginner is the Minix source code, which shows beyond a shadow of a doubt how to load and run a.out programs.

[bluecode]

lol, sry :-[

[distantvoices]

@kernel64: Well, I'm using elf binaries. have an elf kernel, elf services, elf libs and elf user programs. Upon loading I simply strip off the first 4096 bytes of the file - which contain the elf stuff as far as I know. I'm gonna extend this by a loader and dynamic linker in the ... far ... future, as soon as time allows extensive coding again.

To simplify things, I merely link the binaries to a given virtual address - so no relocation is necessary.

As for the shared libs -- they gonna be an extension to shared memory.

Stay safe

[bluecode]

Second try to make a post ;D
Copy&Paste in Linux is just not what it should be >:(

I also have got a elf loader, which doesn't do any relocation, because I link all my programs to virtual address 0. Relocation is a little bit more difficult, but not very. You have to go through the section table and through the relocation section and through the symbol section.
I would not use a.out first, because elf is very simple.

edit: Elf loading (without relocation) is just going through the segments and loading them, no more, no less.
@BI: What you do seems to be a workaround/hack/... ("Notl?sung" if you know what I mean ;D )

[distantvoices]

It's not really a "Notl?sung" (i.e. makeshift,emergency solution; I 'm pretty capable of German for that's my native tongue) but rather something which grew out of some kinda longing to get the thing going without tampering too much with details - they come later, the place and the hooks are there.

In the meantime it's perfectly possible to start a simple textfile as a process and then wondering: Oh, it bails out... coz there is no test if thet's really an executable. Shame on me.

[bluecode]

It's not really a "Notl?sung" (i.e. makeshift,emergency solution; I 'm pretty capable of German for that's my native tongue) but rather something which grew out of some kinda longing to get the thing going without tampering too much with details - they come later, the place and the hooks are there.

I know that you're from Austria and your native tongue is German. I'm from Germany. I used the german word because I'm not "pretty capable" of English and wasn't sure you understand what I mean. ;D

[Pype.Clicker]

so far, clicker do not support "plain" ELF files ... it does have its own binary format that includes a "script" telling the OS what is to be done to have the program loaded (e.g. create a stack here, load those bits there, create code segment here, create thread executing this, etc).

But i do have a tool that gets an ELF file and produces the "custom binary file" out of it (plus command-line statements such as "what function should be thread entry point). User programs are not relocatable so far (most are still coded with asm wizardry)

I have another tool that does similar stuff with kernel modules, but here the resulting file is relocatable and enjoys dynamic linking against other modules and kernel symbols. It even has extensions that can instruct the kernel to load other module first, to display hints/warnings at the users, to notify that the module is actually a driver for a specific device, etc.

Probably all those features could be achieved with plain ELF files too, that was just not part of my initial design plans.

[Legend]

Statically linked ELF files are no problem ...

[bubach]

I thought that i should post this link here:
http://www.cs.umd.edu/class/fall2004/cmsc412/proj1/

Not sure if it will help anyone or if it's intresting, but..

[Pype.Clicker]

(damn' i missed the deadline). Seems interesting, though.

[pradeep]

Just now gone through the ELF spec. I also like to support a minimal ELF file format without dynamic linking and other such stuff. If you are going to strip the first 4096 bytes then what are the sections you are processing? Just the text and data sections.

[bluecode]

I wouldn't strip the first 4096 bytes like beyond infinity does. You just have to load the elf file header, which is at address 0, than get the address and size of the program header. Than go through the program header and load all the segments you need to load. There's no need to go through the elf section header, because that's only for dynamic linking.