OSDev.org

Memory map of project is 32k (0- 32k)ROM for boot bin, 16k (32k- 48k) stack RAM, then 64k ( 48k - 112k) kernel RAM.
I have boot bin of 20k size, but ROM size is 32k, so i wanted to use 12K space available, and shift some kernel code in boot.

So i made a separate SECTION ( say .BOOT) taking one file ( say common.c) from kernel and built section .BOOT at address 20k in boot linker srcipt ld file. I got the common.elf, common.o, common.bin what ever is needed, either by copying section .BOOT using 'objcopy' or by building only common.o. I programmed this kernel.bin at address 20k in my hardware setup. i used readelf binutil to cross check that common.c functions has got proper address starting from 20k.
Now i want to call functions present in common.c ( burnt as kernel.bin into hw) from kernel during execution.
I included the kernel.h file as needed in kernel build so that kernel compilation can pass. Now i want to use common.elf to link with kernel build so that all references to functions in common.c are resolved. is it possible ? I tried , but linking fails

I dont want to use static lib from kernel.elf, coz it will copy kernel.o again in kernel build which would be 2nd copy of kernel.o. And since its running in HW so i cant make use of shared lib.

Please help !

All you need is a dynamic linker, since you run your own kernel, you need to implement it. Check elf document on "program loader".
However, a fully functional elf parser + dynamic linker may take a few kilobyte in storage and in ram.

Is there no other solution, than dynamic linker?

rajiv123 wrote:Is there no other solution, than dynamic linker?

Linking is either static or dynamic. If you won't use static linking you are only left with dynamic linking.

That said, there are, however many ways to do dynamic linking. You could use a 'jump-table' at a fixed address, function pointers in kernel.bin that are resolved at load time or you could write a simple patch program that patches your code after linking. If you are in protected mode you could do some sort of runtime patching. The x86 architecture may also help because it is a segmented architecture you could put the different modules in different segments and just patch the segment at runtime.

Really there are so many solutions that the most difficult thing may be to choose which one to use.