In my list of steps, I forgot about macOS and enabling CI for arm64 Mac.
It might be less distracting for students if we tell the linker instead of the compiler.
As an experiment I tried the following:
Changed the symbol used in the example solution:
.text
.global actual_hello
actual_hello:
...
Created a linker script text file containing
PROVIDE(hello = actual_hello);
Changed the Makefile so the file name for the above linker script is passed to the linker:
LDFLAGS = my_linker_script
This passes. So perhaps we can use this sort of approach to alias _hello to hello
generators/generate has in prop the name of the function being called, so it could generate the linker script.
(Alternately, if we came up with a different arrangement where we made a tiny per-exercise change to the Makefile instead of introducing a new linker script file, we could generate the various Makefiles from a template.)
I can try to help out for sure. But thereās no way I can put in the officially stated 4 h/week. So if you can live with less, feel free to sign me up.
Your list looks excellent. I guess you have the rights to merge the runner PR? If so, you can go ahead and merge that.
About native macOS support, I played with it a bit more and came across more differences that could be too problematic. Concretely, I looked at hello_world. Apple clangās as doesnāt like .section .rodata. Putting just .data works. However, even then it doesnāt work:
Looks like loading addresses into registers is done differently on macOS. I was able to make it work at some point, but then it didnāt compile on Linux. Maybe there is a syntax that will work for both, but for sure there are things that will compile on macOS but will not work on Linux. It will be fairly tricky to make that work with the Linux test runner. So for now I would suggest we go with the original idea of only targeting Linux.
But I think we should just the makefiles to support native Linux on arm64. Then we could also add a paragraph to the installation instructions for macOS users: they would use a Linux VM (or Docker container) for their native architecture.
In case 4 h/wk are not expected, feel free to sign me up!
The PR is merged now. Can we change the active entry in config.json then to see the test runner in action?
Open items from my perspective:
Update makefiles to support native arm64 Linux and emulated. I have a draft for that locally and could open a PR. Thereās actually not much to change, the compiler and assembler calls work in both versions. Only the qemu call needs to go for native arm64.
Update installation documentation: here, we should also differentiate between native arm64 and other platforms, because you donāt need qemu when using a native arm64 platform; also add a paragraph for macOS users. Iāve played with Lima recently and itās what I would recommend.
In general, maintainers being added to tracks are asked to commit to them, else we get the situation where we have tons of inactive maintainers and then blocked PRs (ie, we removed like 200 inactive maintainers in our last āpurgeā).
For tracks with single maintainers, or responsive-if-needed, this doesnāt matter as much so we donāt enforce it.
Everything can be on a case-by-case basis, but in general that document represents(/ed) what we felt was a good set of criteria/guidelines at the time.
Awesome. Congrats and thank you! Want to PR the config.json flag?
I think itād be good to have at least a few other maintainers look at the track before we officially launch it to the public. @keiraville has created all the exercises and I tried three or so (Iām a beginner with arm64 myself, so itās quite challenging for me), but that was about it.