OSDev.org

MarkOS wrote:For now I'm developing elf header handling and relocation.

I think this is what must I do to execute an elf. Correct my mistakes.
1 - Load ELF file (of course )
2 - Relocate section headers
3 - Get dependencies of the ELF file
4 - Load shared libraries needed (for each library you must do 2, 3, 4 and 5)
5 - Relocate all the ELF replacing external symbols
6 - Execute the ELF!!!

What you describe is static linking. IIRC elf (shared) libraries generally use dynamic linking and position independent code. Read the elf manual chapter 2.

It is dynamic linking. Static linking means all code necessary is put into one single binary.

The ELF manual uses the term "dynamic linking" only when position independent code is used. Using this terminology I would call the process of relocating an object file or linking it to another object file "static linking". (Even if that does not happen at "link-time" but at "load-time".)

ELF Specification 1.1 wrote:When building an executable file that uses dynamic linking, the link editor adds a program header ele-
ment of type PT_INTERP to an executable file, telling the system to invoke the dynamic linker as the pro-
gram interpreter.

wikipedia wrote:Dynamic linking means that the subroutines of a library are loaded into an application program at runtime, rather than being linked in at compile time, and remain as separate files on disk.

That ELF by default uses PIC for libraries, does not mean everything must use PIC. In fact, Windows DLL's are by default to be relocated.

[quote="Wikipedia on "Static library""]Static libraries are either merged with other static libraries and object files during building/linking to form a single executable, or they may be loaded at run-time into the address space of the loaded executable at a static memory offset determined at compile-time/link-time.
[...]
Static library files may also be linked/loaded at run-time by a linker or linking loader (e.g., the X11 module loader). However, whether such a process can be called static linking is controversial.[/quote]

You obviouisly did not read the rest of the article. You're just stripping the context in a futile attempt to get your right

I did read the rest of the article. I think this is basically an issue caused by the terminology of the elf specification.
ELF says that dynamic linking is the process of linking a "shared object" to an "executable file". A "relocatable file" is definitely not the same as a "shared object" (a shared object contains some special sections to tell the os which linker it should use to produce the process image etc.) according to elf. "Relocatable files" can be used to construct "executables" and "shared objects". The op wants to link two "relocatable files" together to create a process image. According to elf this process is called "relocation" and not "dynamic linking".
Of course you can say that this is dynamic linking, too (as the linking is done during run-time); but elf does not call it dynamic linking. :/

Korona wrote:I did read the rest of the article. I think this is basically an issue caused by the terminology of the elf specification.
ELF says that dynamic linking is the process of linking a "shared object" to an "executable file".

What I've described IS linking a shared object to an executable files...
Read, and only after you can talk.

MarkOS wrote:What I've described IS linking a shared object to an executable files...
Read, and only after you can talk.

So you are writing an implementation of ld.so? In this case I was wrong, I'm sorry.

Korona wrote:

MarkOS wrote:What I've described IS linking a shared object to an executable files...
Read, and only after you can talk.

So you are writing an implementation of ld.so? In this case I was wrong, I'm sorry.

Yes
I'm writing an implementation of ld.so, but directly into the kernel.

However if you read well you can understand this already from the first post...

MarkOS wrote:

Korona wrote:

MarkOS wrote:What I've described IS linking a shared object to an executable files...
Read, and only after you can talk.

So you are writing an implementation of ld.so? In this case I was wrong, I'm sorry.

Yes
I'm writing an implementation of ld.so, but directly into the kernel.

Interesting, but doesn't that violate the ELF standard? According to ELF each executable can specify the dynamic linker it wants to use via the .interp section. Each executable can use it's own dynamic linker. On linux most executables use /lib/ld-linux.so.2. but that is not mandatory. But I guess you don't have to worry about different linkers as a hobby os coder. You can safely ignore the .interp section for now and add support for it later.

However if you read well you can understand this already from the first post...

Yes, sorry, I should have read that post more carefully.

Korona wrote:Interesting, but doesn't that violate the ELF standard? According to ELF each executable can specify the dynamic linker it wants to use via the .interp section. Each executable can use it's own dynamic linker. On linux most executables use /lib/ld-linux.so.2. but that is not mandatory. But I guess you don't have to worry about different linkers as a hobby os coder. You can safely ignore the .interp section for now and add support for it later.

Really interesting... In your opinion what are pros and cons of kernel ELF handling and external linker ELF handling?

Korona wrote:Yes, sorry, I should have read that post more carefully.

Don't worry!!!

I've managed to handle modules for my kernel. The relocation and the dynamic linking with kernel symbols works well...Hoping that my code will work for every ELF... So now I need only to import symbols from an external ELF file... It's the most difficult thing I think.

I can also get dependencies of ELF files reading only the DT_NEEDEDs from the .dynamic section.

The only thing I must do is to import symbols from shared libraries needed.
Do you know how to do this?

It has been a long time since I was working with ELF but I believe you have to find the DT_SYMTAB entry, that entry should point to a symbol table. Then simply find the symbol you are looking for and read it's virtual address (that is stored in st_value). I think you can also use the DT_HASH entry for faster symbol lookup.