-
Notifications
You must be signed in to change notification settings - Fork 987
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
Add clang/ARM support for MINIX #195
base: master
Are you sure you want to change the base?
Add clang/ARM support for MINIX #195
Conversation
Fantastic. A huge step in the right direction for minix, bugs or not :) For those who may be interested in helping out with debugging efforts: if you happen to know, are any of the test failures occurring on either the actual hardware or qemu, or both? Specifically, it might be easier to do debugging in qemu. Also, I seem to recall that test75 was already having issues before, so that might not have gotten worse at least? For clarification: given my current project I have -1 spare time for any time unit of -1, so I won't be of much use at least in the short term unfortunately.. |
What is mentioned in the README.md is on HW, for reference here are the failing tests:
On emulation, the results are a bit better / different:
|
Good to know, thanks! For reference, the test-73 crash on address 0x6374652f very much looks like memory corruption: that value is actually the string "/etc" in 32-bit little-endian format, and as such should obviously never be dereferenced as an address :) |
The linker script has been replaced by small adaptations to make sure the required structures are aligned at runtime per hardware requirements. In some cases, the linker script failed to guarantee proper physical addresses alignement. This is important for page entries descriptors which are required to be aligned as the MMU doesn't support unaligned accesses to those. Change-Id: I3e22d3da102230be2534b4261e2c6c937e367de6
Note: GCC is still the default compiler, to use clang do the following: $ BUILDVARS="" ./releasetools/arm_sdimage.sh
What is the status of this PR now? Do all six problems remain? And presumably the OOM in isofs is unrelated to the boot failure in #104? (I recall that was likely a gcc bug?) |
Not to be merged as is, at least I believe the known bugs needs to be sorted out first.
This patch set does not throw away GCC, nor changes the default toolchain for ARM. This will be done when the aforementioned problems are fixed.