Skip to content
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

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

sambuc
Copy link
Member

@sambuc sambuc commented Jan 3, 2017

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.

@dcvmoole
Copy link
Member

dcvmoole commented Jan 3, 2017

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..

@sambuc
Copy link
Member Author

sambuc commented Feb 4, 2017

What is mentioned in the README.md is on HW, for reference here are the failing tests:

  1. 53: Division by zero does not trigger exceptions
  2. 75: ru.tv_secs can't be zero (and is zero)
  3. 85: hangs
  4. isofs: Fails because of an out of memory condition
  5. vnd: crash
  6. Running two times the kyua tests in a row, without rebooting in between will lead to a mostly failed second run because of copy-on-write errors.

On emulation, the results are a bit better / different:

  1. 53:
Test 53 error line 189; i=0x0000000100000000; j=0x0000000000000000; k=0x0000000000000000

/Volumes/Minix/src-arm/minix/tests/test53.c:31: Subtest 0,  error 7,  errno 9: Bad file descriptor
error line 190; i=0x0000000100000000; j=0x0000000000000000; k=0x0000000000000000
/Volumes/Minix/src-arm/minix/tests/test53.c:31: Subtest 0,  error 7,  errno 9: Bad file descriptor
error line 191; i=0x0000000100000000; j=0x0000000000000000; k=0x0000000000000000
/Volumes/Minix/src-arm/minix/tests/test53.c:31: Subtest 0,  error 7,  errno 9: Bad file descriptor
error line 192; i=0x0000000100000000; j=0x0000000000000000; k=0x0000000000000000
/Volumes/Minix/src-arm/minix/tests/test53.c:31: Subtest 0,  error 7,  errno 9: Bad file descriptor
error line 193; i=0x0000000100000000; j=0x0000000000000000; k=0x0000000000000000
/Volumes/Minix/src-arm/minix/tests/test53.c:31: Subtest 0,  error 7,  errno 9: Bad file descriptor
Too many errors; test aborted
  1. 73:
Test 73 VM: pagefault: SIGSEGV 131109 bad addr 0x6374652f; err 0x5 nopage read
rs*F     131109 0x23c34 
PM: coredump signal 11 for 502 / rs
rs*F     131109 0x23c34 
ok
  1. 85: hangs

@dcvmoole
Copy link
Member

dcvmoole commented Feb 4, 2017

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 :)

sambuc and others added 5 commits October 6, 2017 11:28
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
@MerlijnWajer
Copy link

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?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants