OSDev.org

Okay, I'm trying to have a core Elf binary, loaded by GRUB, be able to have a dynamic symbol table which loaded modules may link against.

First I tried to simply have LD produce the DYNAMIC section for the executable. '-E' doesn't work. '--force-dynamic' doesn't work. By doesn't work I mean LD doesn't produce any .dynamic sections.

Now if I separate the functionality needed by modules from the core into a shared object and link it against the kernel then the DYNAMIC section is created unnecessarily (because the dynamic symbols are in the shared object now not the executable), weird but that works so far. Then I attempt to have GRUB load my kernel and my shared object. I am able to load and relocate the module and jump to its DT_INIT function. However, I can't figure out how to get the reloc table of my kernel to be able to dynamic link itself to the now loaded module. I can get the .rel.* section headers from GRUB but all I have is the s_offset. Where is it offset from? I can't figure it out.

I think I'm missing something on either the ELF manual or LD. Either how do I get a .dynamic section in an executable (not linked against a shared object) or how do I get the Elf32_Rel entries after GRUB loads my kernel?

Thank you, any help would be much appreciated.

EDIT: Now that I think about it, I suppose I could have my kernel linked against a null (empty) shared object to coerce LD to produce the dynamic symbol table for it. But that seems arse-backwards and it feels like there could be something simpler and less-hackish.

EDIT: I've thought about it some more. And I suppose that I could use a boot kernel to load my core kernel and link it against the system module. So that'd be a boot executable (not really a kernel) that is loaded by GRUB as sort of a 3rd stage boot loader to load my core executable and system module and perform dynamic linking. That'd make the above a non-problem. Anyone else have any better ideas?

you sholud build your kernel with a symbol table.
then you should build your modules as relocateble files, (link them with ld -r)

then you should parse your elf headers in the corekernel, to get the symbol table.
when you have the symbol table, then you can load your modules at any address, and relocate all the external refarances, so they point to the right function in the corekernel

@blobmeister
Getting access to the symbol table is a little difficult, and ends up being more trouble than it's really worth (well, for me it was)
I just ended up making some macros to create my own symbol table (using the GCC __attribute((section("name"))) feature)

@kokjo
That's what he was trying, the problem is that the non-dynamic symbol table is not usually loaded into memory. Hence, he was trying to get the dynamic symbol table included.

@thepowersgang
it's not that difficult, if you are using multiboot. You check the flags in the multiboot info to see if the bootloader has loaded the symbol table, and then all the information you need is in the multiboot info. You parse it and then... I can see a problem the you is not using multiboot.

Hmm... I remember there was a good reason why I stopped using the multiboot symbol table. Either way, it's a better idea to use the dynamic table (if you can), or roll your own. That way you get control over what is exported from your kernel, and don't clutter your symbol table with unneeded entries.

Also: Some spelling and grammatical corrections for you:
"I can see a problem the you is not using multiboot." should be (if I read this correctly) "I can see that your problem is that you are not using multiboot"
In response, I am, just I don't use that feature, mostly because it makes my memory manager messy trying to work around maintaining that data.

Or you can just use my MAGGOT bootloader.
It links your ELF kernel to all your shared object libs for you, and passes all the dynamic symbol tables to you in a module, too.

An alpha-testing copy is on: http://www.quokforge.org/projects/rebochs/files

Maybe the linker scripts I use for my kernel might help you:
http://xenos.svn.sourceforge.net/viewvc ... iew=markup
http://xenos.svn.sourceforge.net/viewvc ... iew=markup

The first linker script tells ld to put the dynamic symbol table into the "kernel" segment, which is loaded into memory by GRUB since it has PT_LOAD attribute. It also defines some symbols which mark the start and end of the symbol table.

The second linker script defines the symbols which should be exported. (You could put this into the first linker script, too - but I prefer to keep them in seperate files.)

This file contains the linker command line:
http://xenos.svn.sourceforge.net/viewvc ... iew=markup

Basically, the linker flags should be something like this:
-Wl,-shared,-soname=Kernel.elf -T ldscript -T exports.lds
This tells ld to create a dynamic object and assigns a name for this object (in this case, Kernel.elf). If you link your modules against this file, this name will appear in the list of files which are required to load this module.