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. > > Chris >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel