On 17/05/15 14:06, Justin Cormack wrote:
On 17 May 2015 at 14:36, Antti Kantee <[email protected]> wrote:
On 17/05/15 13:03, Justin Cormack wrote:
I found a whole lot more symbols though, eg everything using the macro
CRT_ALIAS in arm eg __atomic_fetch_xor_1 etc. I have a patch to not
build these for rump kernel builds, but it occurred to me that this
could cause issues if you build a mismatched kernel and libc if these
symbols have changed. Is this an issue and do we want to support it?
Where's the patch?
https://github.com/justincormack/frankenlibc/commit/cdc91b60cfaf9d4ab23614852f9ac1cd96def85d
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.
