-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rebase musllibc on top of upstream master #19
Comments
Please can we do this! libmuslc doesn't currently build with gcc-12; the upstream source does. |
@wom-bat: can you make a PR for this? |
I'll try. |
I've created a branch to work on. |
I started working on something similar a few weeks ago. It's probably cleaner to do a fresh fork on top of a recent libmusl version. Things that I would change about a fresh port would be not creating separate sel4 architectures (eg arm_sel4) and instead just change the original architecture code. This simplifies the amount of changes required to add seL4 support. It means that the original architectures don't work, but because there also ends up being seL4-specific changes to common code the original Linux support already isn't preserved. Upstream musl doesn't yet have support for rv32 (although they have it on a roadmap it's not scheduled), and our support for riscv was added before support for rv64 was added upstream. Our support should probably be removed, and replaced with the upstream port. Upstream musl's malloc has a new implementation. The new implementation uses mmap differently, and the basic support provided by libsel4muslcsys isn't enough. It is possible to currently use the old malloc implementation with a configuration flag when building musl. I've attached a commit that I was using on top of the most recent musl release 1.2.3 [1]. It appeared sufficient to start with. [1]
|
https://git.musl-libc.org/cgit/musl/commit/?id=d8f2efa708a027132d443f45a8c98a0c7c1b2d77 is needed sooner, as without it compilation with current GCC fails. |
Any reason why a standard, unmodified libc like newlib isn't used, instead of taking on the burden of keeping a fork up-to-date? That's what we used at my previous work for the applications we loaded (we used the root server as a sort of bootloader, so we could update and reload the application without rebooting the machine). As far as I know the only incompatibility is which register is being used for TLS, but here seL4 picked a non-standard way of doing things too. |
Follow-up from a Mattermost suggestion from @kent-mcleod: rebase musllibc on top of upstream master. Might be worth trying a merge commit there to have sychronization point again.
The text was updated successfully, but these errors were encountered: