Closed boeckmann closed 2 months ago
What's meant by "crash"? It's a 8086 real-mode program, so there aren't that many exceptions that may occur ("divide by zero", "out of memory"?).
My first test with this line:
exec qemu-system-x86_64 -fda ./jwasmr.img -boot a -m 16 -enable-kvm
didn't show any problems. However, if "-enable-kvm" is removed, the program "freezes" ( displays nothing and doesn't return to the cmdline ).
Yes, it "freezes".
I ran the binary both in true MS-DOS 7.1 and in a Windows XP NTVDM ( under Qemu, with KVM ) - no problems.
So to me it rather looks like a Qemu problem.
Maybe, I just wrote the exact same image onto a floppy and tested it on my Pentium MMX system. Indeed this seems to run. QEMU was the last that would have come into my mind regarding a potential source or error. If it is a QEMU thing that would explain why I had a hard time debugging this (in addition to my poor debugging skills).
There is other software crashing under non-KVM Qemu, like 4dos. So this has most likely nothing to do with JWasm.
At least the release version 2.18 and later versions somewhat randomly crash. I will attach a floppy image for use with QEMU or similar where it crashes early, even before outputting the header and usage info. Simply execute JWASMR without arguments. The following do NOT have an impact: DOS kernel (tested with FreeDOS and EDR). Compiler version (tested with OpenWatcom 1.9 and v2). The shell does have some influence on the frequency (SvarCOM crashes most often, EDR command.com least). You may run the image via
jwasmr.img.zip
I was unable to debug this properly, because the debug version does not crash. Also, the non-debug version does not show this behaviour when run for example with lDebug in trace mode. I think you are more experienced with such stuff, so perhaps you get further than me.
I have an idea what might be the cause and got several build configurations that seem to run reliably (they still may corrupt memory, but at least I was able to build the EDRDOS kernel under EDRDOS with this configurations).
I noticed a somewhat odd segment layout if it is built with the .LIB generation step: main module comes first, then the _TEXT segment containing the default library, and then the *_TEXT segments from the JWASM.LIB. This in combination with the
-zc
compiler flag seems to be problematic. If I leave it out and only utilize-zt=1024
to keep _DATA below 64K, it seems to work reliably.It also works WITH the
-zc
flag if a remove the intermediate .LIB creation and link everything directly. The segment layout is different then, containing all the text segments of JWASM first and only after it the _TEXT segment containing the default library.As a sidenote: in the DOS makefile, I think it should be
system dos
and notformat dos
for the linker. This makes the linker find its libraries without having to specify the lib paths via SET.