On Sun, Jun 10, 2018 at 12:38 AM Joel Sherrill <j...@rtems.org> wrote: > > > > On Fri, Jun 8, 2018 at 7:45 PM, Chris Johns <chr...@rtems.org> wrote: >> >> On 9/6/18 10:00 am, Joel Sherrill wrote: >> > On Thu, Jun 7, 2018, 9:01 PM Chris Johns <chr...@rtems.org >> > <mailto:chr...@rtems.org>> wrote: >> > > and what >> > > discussions we need to have to decide between the "bundled kernel.so >> > approach" >> > > (the one implemented here) vs. the "FreeBSD loader.efi+hello.exe" >> > approach. Let >> > > me know! >> > > >> > >> > I do not think I can help too much here. I understand the >> > loader.efi+exe >> > solution and it should work because all RTEMS applications we have are >> > statically linked (I am assuming it is here). I have not looked at the >> > details >> > being used with the -fPIC and .so solution so I cannot comment. I do >> > have some >> > concerns the relocatable exe might expose some dark corners and issues >> > in the >> > host tools we have, for example how does GDB find the base address of >> > the image >> > so you can debug it? and is this just working or is it really suppose >> > to work >> > this way? >> > >> > >> > All I can say is that with Deos/RTEMS, we use PIC on arm, PowerPC, and x86. >> >> I would hope a solution like Deos did provide a seamless way to do this and I >> would also hope they support you. > > > I am not using their normal recommended tool setup for users. This is normal > RTEMS tools building our test executables. At one point, it was our gdb with > their qemu build. They use something like this strictly internally. > > These executables are statically linked EXCEPT for references to, in > the minimum case, two .so's from their environment. I set an argument to > ld to ensure all symbols are resolved at link time. Their boot process > associates > the .so files with the partitions. It is dynamic loading but it is statically > configured > and not touched after boot. > > I haven't had any special help from them in this area except figuring out the > arguments and linker scripts. When I have access to a build log, I am happy > to post the build of hello world for comparison. > > I have no idea how this compares to UEFI booting except to say that PIC > hasn't introduced any tool issues in our GNU tools. libdl may have issues > but we aren't using it yet. I can check if the tests pass or are disabled. I > don't remember. But that may be illuminating. > >> >> >> > We >> > have spent a lot of time debugging with gdb attached to qemu. >> How does GDB get the relocatable load address to map to the symbol table? >> >> The libdl code supports the same protocol/design as NetBSD and other systems >> in >> informing GDB about the address of loaded modules. There is a series of >> symbols >> and tables maintained that GDB knows to examine to find the load addresses of >> object files. >> >> > I haven't seen any tools issues yet. >> >> Yet? Once the path is settled it will be difficult to change so all I am >> asking >> is the detail be checked and understood. RTEMS does not support shared >> libraries >> the same way Linux or other Unix systems do. I do not understand enough of >> the >> low level and the standards all this is based on to help decide. >> >> An example of an issue where a relocatable kernel with an unknown load >> address >> creates a problem is libdl. The testsuite uses the 2-pass approach >> (rtems-syms >> --embed) which should be OK however the other approach where the symbol >> table is >> not embedded and built on the host would fail. It is a small issue but it >> shows >> how things can subtly break. > > > I'm not relocating any RTEMS code with Deos. Our code is linked to a static > address > ranges and invokes Deos methods in the shared libbary. > > I know this doesn't prove anything concretely about the UEFI exe but it is > the closest > example we have. PIC is likely OK. The .so magic could be problematic as it > looks > like I effectively build a static exe.
The Bsymbolic flag isn't a requirement for this system to work - it just helps eliminate the use of the GOT/PLT unnecessarily. Personally, I don't think I have the clarity to be able to say whether this is or isn't safe - I think the only way to be able to tell will be to continue with my work on it and to prove that it either does or doesn't, at least in the general case. What we aim with the hello.so method is the same as you said - effectively building a static fully resolved exe, with the difference that this _is_ relocatable depending on the UEFI firmware's access and availability to memory. I can't speak to how libdl is affected - but the bit from the ld manual about "platforms which support shared libraries" doesn't imply libdl / RTEMS needing to support shared libraries to me. What we build in this method is hello.so (which includes all of RTEMS' kernel + the user application (hello world here)) - the platform that needs to support shared libraries then is the UEFI firmware, which from my understanding _does_ support it, after we convert the SO to a PE. My view on next steps is to examine potential side-effects of every linker/compiler option we're introducing and summarize and discuss them here (starting with the Bsymbolic one, for eg.), and perhaps to extend the POC I have that has efi_main->bsp_start working to also manage efi_main->boot_card. Extending the PoC will be about a week of effort, by my estimate, to be hacky - in terms of staying on track, that could be a lot of time to waste, so I think I'll leave the decision to you - we're a bit ahead, so we may be able to absorb the hit if we change our mind. P.S. - I think this thread is getting a bit long and this may better be discussed on a call so we can settle on a more concrete list of what is and isn't resolved from each of our ends. Let me know if you see it that way - I'm okay with a benevolent dictator's hammer decision too :) Cheers! >> >> >> Chris > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
