On 9/6/18 2:39 am, Amaan Cheval wrote: > On Fri, Jun 8, 2018 at 7:31 AM, Chris Johns <chr...@rtems.org> wrote: >> On 08/06/2018 01:50, Amaan Cheval wrote: >>> >>> Joel, Chris, I'd appreciate guidance on what I ought to work on next >> >> I would like to see the focus on the kernel context switcher, FPU support, >> and >> then interrupts so we have the basic drivers we need like a tick interrupt >> running. >> >> This assumes the loader issues we have not resolved do not effect this work. >> > > They do affect it to a certain extent - I'd be working semi-blind > since without tying the loose ends required to boot, I wouldn't be > able to test the implementations of the areas you mentioned. I'm not > at that point yet, but I suspect I will be within a week or so, so the > sooner we determine the approach required for booting, the better.
OK. >>> 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? > > Well, these images won't simply _run_ through GDB, no - but here's > some stuff that may be helpful to see: > https://gist.github.com/AmaanC/4e1aaa2cbdda974b93c5a3e1eac5318a Interesting and thanks. Is this with QEMU? > One concern of yours was the unnecessary addition of the GOT/PLT. > Thankfully, through options like -Bsymbolic, we can circumvent the > GOT/PLT for all symbols which have already been resolved (as you'll > see happens for "InitializeLib", "Print", "boot_card", etc. (boot_card > because this is from my WIP version trying to get boot_card to work > with this method too)). The -Bsymbolic option is an example of my concern and stepping into a dark corner. It could also be my lack of understanding. Yes it works but is that always going to be the case? For example the GNU ld manual states: "This option is only meaningful on ELF platforms which support shared libraries and position independent executables." and technically we do not support shared libraries so is this usage a normal use case? I do not know. Also Oracle says the option is somewhat historic: https://docs.oracle.com/cd/E19957-01/806-0641/chapter4-16/index.html > I'm definitely concerned, but having looked at it more, I can't find > anything specific that would genuinely cause problems besides > unresolved symbols - we could have a build-time check for them, > though, failing the build when that's the case (-Wl,-z,defs does it). If loader.efi+exe avoids this then it makes sense to me to do so. The less we bend or stretch the more stable the support will be over time. > So for next steps, I guess you'll be looking into how the use of -fPIC > may affect us, and we can work on addressing those concerns, right? I do not know because I do not know risks. > I > personally preferred the static build approach too, since that way we > can "plug" loaders in: > - loader.efi for UEFI firmware > - multiboot header + 32 to 64 bit mode code for Multiboot > Agreed. > That's a slight oversimplification since (1) needs to be packaged on > the filesystem with the static hello.exe Yes this is a good point, then again this target is a bit different to other targets. Users of PCs and similar hardware are use to boot loaders and managing them plus handling the media needed. I do not think we will ever create a bootable within an RTEMS build. Could I install FreeBSD, load an RTEMS kernel onto the root directory and then boot it with the standard FreeBSD loader.efi chain? > and (2) needs to be linked in > with it, but I think the build system retains more of its separations > from the boot method this way (though I can't be sure given my > relatively naive view of RTEMS + autotools). I can help here if you need it. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel