Module loader

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
Rui

Module loader

Post by Rui »

I have a toy OS.
How do I make a module loader?

IF I make an assembly routine, for example:
-------------------------
GLOBAL _myfunc

_myfunc:
    ...some code...
    ret
-------------------------

compile it has an object ( bin? elf? ...)

Make an header file to declare this function and make C programas use it?

how do I load it and make new programs aware of it?

any directions are wellcome!
Thanks a lot!
carbonBased

RE:Module loader

Post by carbonBased »

First off, don't try to link in binary formats... you wont get very far.  What you need are object formats.  ELF, COFF, RDOFF, etc.  You need a file format that defines all the symbols withen.  A binary format will not do this... and I don't believe an ELF executable will either, however an ELF object will.

Essentially, all you must do is load this object file into memory, parse the object header, create a symbol table (symbol name -> symbol address mapping) and perform address relocations.

My OS (ndk) has an RDOFF2 run-time linker build into it, and can be found at www.neuraldk.org

--Jeff
Rui

RE:Module loader

Post by Rui »

Thanks!
I check your code to see if i understand it.

Regards.
Rui

RE:Module loader

Post by Rui »

Hum... I've seen your code...

1).- Load object... Easy.
2).- Parse the object header...??? ( objdump -D ??? )
3).- Create table: name -> symbol address mapping ... Shouldn't be hard after point 2 is solved.
4).- perform address relocation... ??? - sounds dificult!

Could you elaborate or point me to information on how to do points 2 and 4?

thanks!
carbonBased

RE:Module loader

Post by carbonBased »

Well, it's been some time since I last wrote it, but here's how I do the run-time linkage.

First off, I have a list of symbols I wish to export to these modules (rZeroExports, line 33).  This is mostly a security thing -- I don't want these modules to be able to call every kernel function; only a few.

Also, since I build my kernel as a binary format (soon to be my own format, based on RDOFF2) I maintain this explicit list of exports, rather then attempting to parse through the actual binary symbol table (as it will probably be changing in the future).

I also maintain a list of symbols the kernel expects to import.  This is also necessary, as I don't want a module to be able to overwrite a symbol already defined in the kernel.

The parsing routine basically consists of filling in the imports structure, and providing the object with the symbols in the exports structure.

If you're using RDOFF2, like me, the meat of this part can be found in rZeroParse() which simply looks through the header information (the first portion of the object in memory) and collects as much information as possible.  First it checks that is it, indeed, an RDOFF object, and grabs the length of the header.

At this point, I actually skip past the header information to read the segment information first (can't perform relocations on segments when you don't know where the segments are defined!).

I then skip back, and do the actual relocations.  Look through the actual nasm docs for info on how these header and section portions are defined, as that'll probably make my code make more sence.  I wrote this code entirely from these docs, and the nasm utilities code.

Basically you go through this list of relocations and, if its an export, record it in the imported symbols list.  If it's an import, then you'll have to get the address of the symbol it is looking for (defined in exports list) and calculate its relative address from where it's being referenced.

This is a pretty general response, but the concept really isn't too bad once you've gone through the nasm docs, and their sample code.  For example, the objdump utility can be used as a basis for reading in all the header and section info, while the linker source can be used as a basis for the actual run-time linking.

--Jeff
Guest

RE:Module loader

Post by Guest »

>My OS (ndk) has an RDOFF2 run-time linker build into it, and can be found at www.neuraldk.org
>
>--Jeff

ELF and COFF linker for kernel modules:
http://my.execpc.com/~geezer/osd/exec/runreloc.zip
Rui

RE:Module loader

Post by Rui »

I've dowloaded de nasm documentation (200+ pages pdf!).
I will go thruh it, look at your code and your explanations.

Now I certanly see things more clearly.

Thanks a lot!
carbonBased

RE:Module loader

Post by carbonBased »

200 pages?  That seems extreme... I'm just talking about the standard nasm distribution which has an rdoff/doc directory that's supposed to contain docs on the format... shouldn't be that big...!

--Jeff
Post Reply