On 17 May 2015 at 15:46, Antti Kantee <[email protected]> wrote: > > Superficially, that looks like maintaining the status quo and I don't think > that committing it as such requires discussion. > > However, I have recently started thinking that the history-derived notion of > rump kernels not containing toolchain runtime symbols is actually wrong. > Even if the opposite is not right, relying on the runtime coming from libc > is definitely wrong. Consider e.g. the lowRISC minion core offload > scenario. The rump kernel at the "server side" doesn't functionally need a > libc, but linking one in is required just to appease the toolchain runtime. > rumprun-baremetal used to include the relevant bits of compiler-rt to make > it possible to link it without libc, but I got tired of maintaining that > hack. It would be cool if a freestanding rump kernel without libc would JFW > without having to scrape the toolchain bits from somewhere. >
There is another problem - unlike the __aeabi_* symbols and the __sync_ ones, these do not seem to be standard, so Linux on arm does not supply them as far as I can see. So programs linked against rump+linux libc rather than rump_netbsd libc are going to have issues if they need these symbols - we havent run into the issue as nothing has actually needed them yet. Justin
