Stas Sergeev

But the idea is not too bad. It seems I can arrange the link script for solib, which does essentially what you proposed.

No relocations - just an undefined symbol. I am not sure why it is so but I think it doesn't matter for my needs. Perhaps undefined symbol and the COPY...

> It is probably best to check that the output fdppkrnl.elf file does actually have the needed relocations > --- readelf -r or readelf -d should give something. That unfortunately...

OK, I pushed what I currently have, into a separate branch. You can see that solib is created properly, but writing a dynamic loader is a big task. :(

Does anyone have a simple dlopen() examples to steal the code from? :) I am not going to write a dynamic linker...

My current theory of what's going on, is this: - No matter whether we link exec or solib, we will not see the relocations there. That's simply because R_386_16 (among...

I committed the linker script arrangements alone so that you can play around solib now and it will work: you can boot dosemu from it, or you can make the...

And also I think the solib approach is actually broken. IIRC normally text relocations to undefined symbols are bound to local bss. Later you have a COPY reloc to move...

I _think_ its a bug, because of 2 things: - It doesn't even warn about an undefined global symbols in text segment. - It doesn't seem to propagate the symbol...

And if I link the x86_64 solib, then I (correctly) get this for all relocs smaller than the native word size: ``` ld: kernel.o: relocation R_X86_64_16 against `INIT_TEXT' can not...