On 6/6/18 5:06 pm, Amaan Cheval wrote: > On Wed, Jun 6, 2018 at 6:55 AM, Chris Johns <chr...@rtems.org> wrote: >> On 4/6/18 7:49 pm, Amaan Cheval wrote: >>> Please let me know if that approach doesn't make sense - given that >>> there is no dynamic loader in the RTEMS kernel as far as I know, >> >> There is a dynamic loader in RTEMS called libdl. It is not based around the >> ELF >> standard loader used for shared libraries and will not be. GOT and PLT do not >> add value to RTEMS because we do not have an active virtual address space >> with >> paging. >> >> The libdl code is currently supported with the i386 static builds. I would >> hope >> this would continue to be supported without major refactoring of that code. >> There are tests in the testsuite under libtests. > > Hm, so libdl can load static ELFs and handle those relocations itself? > In that case we could go the "FreeBSD" way more easily as I outlined > earlier; a loader UEFI application image (loader.efi) + the > application image to be found on the filesystem and loaded through > libdl, which we somehow call through loader.efi. > > loader.efi -> libdl -> hello.exe (static executable ELF now) >
libdl is not designed to do this and do not think it could be made too. It needs a full RTEMS kernel located to run. >> >>> what >>> we really want _is_ a static file, but for it to be a relocatable PE, >>> we need to convince GCC to spit out a relocatable but fully resolved >>> shared library. >> >> It is not clear to me yet making the kernel relocatable is free of other >> possible issues. I will need to find time to review all the low level parts >> here >> and my time is currently limited. >> >> Does this UEFI work effect the score context switcher, interrupts, etc? If is >> does we will need to resolve what happens and if not should we consider >> leaving >> it if we can? > > It affects it in the sense that it's all compiled with fPIC, yes. It > needs to be if we're bundling it all together (creating hello.efi, > which includes the UEFI boot code, all of RTEMS, and the user app). > >> For example can iPXE chain load a multiboot image? > > Yes, we could just use Multiboot too. One thing to note, though - > Multiboot will drop us in 32-bit protected mode, whereas 64-bit UEFI > firmware will load is into 64-bit protected mode. Ah OK this is a good point and boards like a Minnow have a 32bit or 64bit BIOS or what ever it is called on those boards so this may not work. > Supporting Multiboot > too will involve adding some code to move to 64-bit mode before > actually calling into the generalized 64-bit mode code. Can it be used as a step towards another solution? > >> >> Sorry to have disappeared for a period at a critical time in this >> discussion, it >> was beyond my control. > > No worries! Hope everything's okay! > Thanks and yes. > I'll look into libdl further in the meantime and continue to polish up > the stub to reflect more of the x64 features, while we figure out our > boot direction. Great. I hope to be back full time next week and I can have a look. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel