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.
Hey guys
I've implemented an ELF loader which does simple relocation on my files and loads all sections marked with the LOAD flag.
I wanted to code a function which loops through all exports and returns the address of the exported function, but then I found out that the .strtab section is not marked as LOAD and therefore my loader wont map it to the memory.
How should I implement that function the best way?
Should I simply attach it to the start / end of my loaded file?
How is it done on Linux?
Thanks in advance!
Hi,
I do this is my kernel:
+ I load sections and map them
+ I use the raw elf blob to deduce where the symbols are
+ I add the offset of the mapped address of their sections.
Then in order to relocate, I use a dictionary of symbols for the elf file which include non exposed symbols, and I use a symbol table of public exported symbols.
Boris wrote:Hi,
I do this is my kernel:
+ I load sections and map them
+ I use the raw elf blob to deduce where the symbols are
+ I add the offset of the mapped address of their sections.
Then in order to relocate, I use a dictionary of symbols for the elf file which include non exposed symbols, and I use a symbol table of public exported symbols.
Thanks!
Well I do the relocating directly when executing the elf so I have access to the raw data of the elf file.
What I actually need is access to the string tables (when I DONT have access to the old elf raw data) and Im not sure if I should map it to the memory, or read it from disk when needed or if there is any better way at all.
In ELF, the symbol names are only in a loadable segment (you should probably use segments rather than sections when loading executables) when the binary is a shared object, otherwise as far as the tools are concerned they are useful only for the static linker (and therefore not loaded at runtime).
It would probably help to know exactly what sort of executable are you trying to load the symbol names for. Is it for kernel modules, shared libraries or simple executables (i.e. user mode programs)?
jnc100 wrote:In ELF, the symbol names are only in a loadable segment (you should probably use segments rather than sections when loading executables) when the binary is a shared object, otherwise as far as the tools are concerned they are useful only for the static linker (and therefore not loaded at runtime).
It would probably help to know exactly what sort of executable are you trying to load the symbol names for. Is it for kernel modules, shared libraries or simple executables (i.e. user mode programs)?
Regards,
John.
Its for my usermode programs, but since I didnt add virtual memory yet (because it simply never completely worked) I compiled a relocatable shared library which can run as a program.
I just added "--pic-executable" to my linker options.
Since I have no clue about ELF files even though I read through alot of docs already, Im not sure if thats right.
Its probably easier to get virtual memory working (so you can statically link to a defined address within each address space) than trying to get PIC working and dynamic loading (most OSs tend to implement virtual memory before dynamic linking/shared objects for example).
Having said that, if you do want to go down the PIC route, what you'll need is to compile all .c files with the -fpic/-fPIC option (see the manual for the difference) and then link with the -shared option. You then need to implement a dynamic loader for your kernel which parses the .dynamic section in the ELF file and does the relocations as required.
An alternative is to produce relocatable executables. For these, you compile as normal (i.e. no PIC), but link with the -r option. This essentially links all your object files into one big object file. At load time you then have to patch up the relocations again, but this time by parsing .rel/.rela sections. It has the benefit of not requiring position-independent code, which is generally slower. The downside is that it becomes more difficult to integrate a library produced this way into multiple address spaces (when you get to this point). Having said that, it is an excellent choice for kernel modules (which are loaded to the same place in each address space), and (as I do) for generic executables in a single-address space OS, although this is a bit of a niche market.
On the whole though, you are probably better off trying to get virtual memory working and linking all your executables statically to a fixed address (e.g. 0x400000 as per x86 Linux).
