<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 8, 2018 at 7:45 PM, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 9/6/18 10:00 am, Joel Sherrill wrote:<br>
> On Thu, Jun 7, 2018, 9:01 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a><br>
</span><span class="">> <mailto:<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>>> wrote:<br>
> > and what<br>
> > discussions we need to have to decide between the "bundled kernel.so approach"<br>
> > (the one implemented here) vs. the "FreeBSD loader.efi+hello.exe"<br>
> approach. Let<br>
> > me know!<br>
> ><br>
> <br>
> I do not think I can help too much here. I understand the loader.efi+exe<br>
> solution and it should work because all RTEMS applications we have are<br>
> statically linked (I am assuming it is here). I have not looked at the details<br>
> being used with the -fPIC and .so solution so I cannot comment. I do have some<br>
> concerns the relocatable exe might expose some dark corners and issues in the<br>
> host tools we have, for example how does GDB find the base address of the image<br>
> so you can debug it? and is this just working or is it really suppose to work<br>
> this way?<br>
> <br>
> <br>
> All I can say is that with Deos/RTEMS, we use PIC on arm, PowerPC, and x86.<br>
<br>
</span>I would hope a solution like Deos did provide a seamless way to do this and I<br>
would also hope they support you.<br></blockquote><div><br></div><div>I am not using their normal recommended tool setup for users. This is normal</div><div>RTEMS tools building our test executables. At one point, it was our gdb with</div><div>their qemu build. They use something like this strictly internally.</div><div><br></div><div>These executables are statically linked EXCEPT for references to, in</div><div>the minimum case, two .so's from their environment. I set an argument to</div><div>ld to ensure all symbols are resolved at link time. Their boot process associates</div><div>the .so files with the partitions. It is dynamic loading but it is statically configured</div><div>and not touched after boot.</div><div><br></div><div>I haven't had any special help from them in this area except figuring out the</div><div>arguments and linker scripts. When I have access to a build log, I am happy</div><div>to post the build of hello world for comparison.</div><div><br></div><div>I have no idea how this compares to UEFI booting except to say that PIC</div><div>hasn't introduced any tool issues in our GNU tools. libdl may have issues</div><div>but we aren't using it yet. I can check if the tests pass or are disabled. I</div><div>don't remember. But that may be illuminating.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> We<br>
> have spent a lot of time debugging with gdb attached to qemu.<br>
</span>How does GDB get the relocatable load address to map to the symbol table?<br>
<br>
The libdl code supports the same protocol/design as NetBSD and other systems in<br>
informing GDB about the address of loaded modules. There is a series of symbols<br>
and tables maintained that GDB knows to examine to find the load addresses of<br>
object files.<br>
<span class=""><br>
> I haven't seen any tools issues yet. <br>
<br>
</span>Yet? Once the path is settled it will be difficult to change so all I am asking<br>
is the detail be checked and understood. RTEMS does not support shared libraries<br>
the same way Linux or other Unix systems do. I do not understand enough of the<br>
low level and the standards all this is based on to help decide.<br>
<br>
An example of an issue where a relocatable kernel with an unknown load address<br>
creates a problem is libdl. The testsuite uses the 2-pass approach (rtems-syms<br>
--embed) which should be OK however the other approach where the symbol table is<br>
not embedded and built on the host would fail. It is a small issue but it shows<br>
how things can subtly break.</blockquote><div><br></div><div>I'm not relocating any RTEMS code with Deos. Our code is linked to a static address </div><div>ranges and invokes Deos methods in the shared libbary.</div><div><br></div><div>I know this doesn't prove anything concretely about the UEFI exe but it is the closest </div><div>example we have. PIC is likely OK. The .so magic could be problematic as it looks</div><div>like I effectively build a static exe.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Chris<br>
</font></span></blockquote></div><br></div></div>