gcc kernel crash upon initialisation, due to using HMATEXT memcpy implicitly in DoConfig
ecm-pushbx opened this issue · 8 comments
I assume this crash was introduced by ee255d2
I tested that the kernel still did build with gcc, but I failed to test whether it also still runs. Turns out that apparently changing the pointers to static made it so gcc put the structure into the init data segment and implicitly called memcpy to put it on the stack. That's wrong, however. We depend on #define to convert all calls in init to the init text copies of memcpy etc. The implicit call by gcc however attempts to call the HMA text copy of memcpy which happens to be at another offset.
Sorry for this headache! I will test a fix soon.
Confirmed that it is that particular commit. Building the prior one with gcc makes it run fine.
Prepared an additional patch which teaches gcc to use the correct helper functions in tkchia/gcc-ia16#109 (comment)
If you want, I can add this to the current or a new PR.
Another thing: The CI test currently only checks that the kernel files exist. Perhaps we could build a test image (eg using bootimg) and check that it boots in a qemu VM? Might need a shell like FreeCOM though. I have some experience running boot loader tests which use a timeout to terminate either dosemu2 or qemu in case the expected quit command is not run.
Perhaps we could build a test image (eg using bootimg) and check that it boots in a qemu VM?
Sounds good to me. I always tend to use Dosemu2 with python-pexpect myself for testing, but I'd like to see a different approach using qemu.
Yes it would be nice to have ability to test booting
@PerditionC Will you merge the PR fixing this bug? Ideally still today (my build starts in 4 hours).
Perhaps we could build a test image (eg using bootimg) and check that it boots in a qemu VM?
Sounds good to me. I always tend to use Dosemu2 with python-pexpect myself for testing, but I'd like to see a different approach using qemu.
@andrewbird do you know whether I can modify the .github/ files and the CI will pick up these changes if I post them as a PR?
Yes that should work. Though if you need to add any more lines to the 'package install' step you should probably create a ci_prereq.sh script and just call that from the workflow instead.
Yes that should work. Though if you need to add anything more lines to the 'package install' step you should probably create a ci_prereq.sh script and just call that from the workflow instead.
I only need qemu-system-x86 and mtools (plus possibly some utilities needed for the timeout), as I intend to include ldosboot, bootimg, and lmacros source files verbatim. (To harden against my server possibly changing or disappearing.)