Is there any example at implementing dlsym(3)?

[technix]

This is part of porting libobjc2 to a kernel, which can also be used to implement a modular kernel along with dlopen(3) even without libobjc2. With a multiboot kernel, how to implement dlsym(3) to allow dynamic lookup of symbols?

[egranata]

This is by no means a complete implementation, but it works for very basic use cases and might help you get started: https://github.com/egranata/puppy/blob/ ... /dlfcn.cpp

Main advantage is that it is entirely in userspace, all it asks of the kernel is the ability to map a region of memory (it's 32-bit Intel, so if you can read it, you can execute it)

[Korona]

mlibc (which is the C library of my OS) has a dynamic linker that shows how it is done in general.

For the special case of a kernel module, I have a complete gist for ELF loading and dynamic linking to the kernel itself. As it cannot handle arbitrary dependencies and the full ELF feature set, this code is considerably shorter and easier to understand than mlibc. The symbol resolution is done in the function lookup(). It uses eligible() to check if a given symbol is exported and elf64Hash() to compute the ELF hash function. The symbol lookup is only about 35 lines of code.

[klange]

I'll throw my chips in here...

As an alternative to dynamic linking, I do runtime static linking of kernel modules, similar to Linux.

I also have a userspace dynamic linker that has rudimentary implementations of (most of) the dl* functions (good enough for Python).

[pvc]

dietlibc has nice and easy to understand implementation. Check /ldso.c file.

[technix]

I am using dlsym(3) in kernel here as part of dynamic binding process of Objective-C language and its runtime library libobjc2. Keep in mind that Objective-C uses exclusively dynamic binding for any and all method calls. The user mode has its own separate libc and dlsym(3) implementation as part of ld.so.

[Korona]

We understand that. That's why I posted a more-or-less freestanding gist and klange posted his module implementation. Why is that not enough? What exactly do you ask for?

[technix]

We understand that. That's why I posted a more-or-less freestanding gist and klange posted his module implementation. Why is that not enough? What exactly do you ask for?

I need a dlsym(3) that is capable of resolving symbols of the kernel itself, even without or before loading any modules. libobjc2 maps this:

Code: Select all

GKProcess *process;
[process killWithSignal:SIGTERM];

into equivalent of this:

Code: Select all

__objc_GKProcess_killWithSignal_(process, NSSelectorFromString("killWithSignal:"), SIGTERM);

through dlsym(3) of the symbol listed above.

[klange]

I need a dlsym(3) that is capable of resolving symbols of the kernel itself, even without or before loading any modules. libobjc2 maps this:

You talked about building modular kernels, so we provided more complete solutions for loading modules.

Implementing dlsym on a single object is as simple as writing a function that looks at a table mapping strings of symbol names to symbol values, and storing your symbols in that table. You can do that in a few different ways. I do a two-pass kernel build where I generate an object file with all the symbols. You can also make sure the actual ELF symbol table for your binary is loaded into memory, but that's a bit tricky.

[technix]

I need a dlsym(3) that is capable of resolving symbols of the kernel itself, even without or before loading any modules. libobjc2 maps this:

You talked about building modular kernels, so we provided more complete solutions for loading modules.

Implementing dlsym on a single object is as simple as writing a function that looks at a table mapping strings of symbol names to symbol values, and storing your symbols in that table. You can do that in a few different ways. I do a two-pass kernel build where I generate an object file with all the symbols. You can also make sure the actual ELF symbol table for your binary is loaded into memory, but that's a bit tricky.

For my system the symbol table need to be pre-populated with in-kernel symbols before any modules are loaded, and then new symbols from modules need to be be added upon loading.

[klange]

For my system the symbol table need to be pre-populated with in-kernel symbols before any modules are loaded, and then new symbols from modules need to be be added upon loading.

Which is what my kernel - which I have already linked for you - does.

You will not find a tutorial on how to implement this functionality. However, we have provided several example implementations for you to peruse.

[technix]

For my system the symbol table need to be pre-populated with in-kernel symbols before any modules are loaded, and then new symbols from modules need to be be added upon loading.

Which is what my kernel - which I have already linked for you - does.

You will not find a tutorial on how to implement this functionality. However, we have provided several example implementations for you to peruse.

Is there any way to make sure linker and Multiboot keep ELF symbol table intact? This way I can use the same ELF symbol table parser for both in-kernel symbols and loaded modules.

[pvc]

I've had problems with GRUB !NOT! loading symbol tables as well. I've had to load all of the headers on top of what GRUB does.

[Korona]

The proper way to handle this is to make sure that the symbols appear in the dynamic symbol type (referenced by the DYNAMIC PHDR). That way, you do not have to rely on GRUB (or any other loader) to get load an external table and your kernel will work even after being strip'ed.