Program misbehaves when using -zm - was: Miscompilation when using (-0) 8086 real-mode DOS target, working for (-1) 80186 higher targets
#862
Comments
johnsonjh
changed the title
|
Hi, I am not sure what you are trying to achive. |
|
I regularly compile for 16-bit and 32-bit DOS and OS/2. However, this bug affects only 16-bit real-mode MS-DOS and only 8086 (-0) builds. G compiles, the resulting binary starts, but G itself is completely unusable - almost every function of the program misbehaves (as described above). 8086 DOS G build is as follows: wcl -k32767 -bcl=DOS -DDOS=1 -DASM86=0 \
-0 -ml -fpi -zm @g.lkr -d0 -s -zq -oabls \
-zp2 -fe=g86.exe g.cIf I change the -0 to -1 (to build for 80186) or higher, everything is fine. Every other OpenWatcom build is fine. |
|
I tried to compile current git version for 16-bit and 32-bit DOS and it is completely broken WATCOM stuff. result of 16-bit DOS compilation result of 32-bit DOS compilation |
|
It works just fine here - those errors indicate you didn't supply the correct arguments, and is the expected output if you are missing at least the "-DDOS=1 -DASM86=0" flags. Building as follows (assuming the WATCOM, PATH, INCLUDE, and other relevant variables are correctly set): DOS 8086 16-bit build: DOS 80186 16-bit build: DOS 80386 32-bit build: I tested just now using a fresh checkout of G, and the g8086.exe binary misbehaves, but the g186.exe and g386p.exe binaries work fine. Using OpenWatcom V2, I regularly build six variants, 16-bit DOS 8086, 16-bit DOS 80186, 16-bit DOS 80286, 16-bit DOS 80386, 16-bit OS/2 80286, 32-bit OS/2 80386, and the only build that misbehaves at runtime is the 16-bit DOS 8086 build. Edit: I am building on 64-bit Linux, if this is relevant. The resulting DOS binaries are tested on a real DOS system, as well as DOSBox and 86Box emulators. |
|
In case this helps, here are three fresh builds of G (commit Left to right is 16-bit 8086, 16-bit 80186, and 32-bit 80386, showing what happens after pressing
|
|
Sorry how you can mix different architecture instruction. |
|
I'm not sure what you mean? The 8086 and 80186 binaries are 16-bit MS-DOS only. I always test them on a real IBM XT running DOS. There is no 32-bit code at all used in the 16-bit builds. (G supports just shy of 70 different platforms, ranging from 16-bit to 64-bit.) |
|
These are the exact three DOS EXE binaries, which I just compiled in the screenshot above, using OpenWatcom V2 (gzip compressed). The first one, the 16-bit 8086 binary, malfunctions at runtime as explained above (both in emulation as shown, as well as on real 8086 hardware - an IBM PC XT running MS-DOS 5): 16-bit MS-DOS 8086: g86.exe.gz For completeness, this is the exact same source code, but built for 8086 16-bit MS-DOS using Microsoft C 8.00a, which works fine. I now regularly build for DOS using Microsoft C 7.00b, Borland C 5.02, and many other compilers, all work fine. |
|
How you can run movsd on 16-bit CPU, it is movsw on 16-bit CPU (same opcode) but different operand and different functionality? |
|
Anyway you should fix your code for in-line memory functions/macros to use unsigned type not short. |
I'm not sure what you mean here. You can verify that there is actually no such instructions compiled in the code whatsoever. Since these builds for DOS are made using I think you are being confused by code which is not compiled at all for DOS. You can confirm this by running the just the preprocessor.
As you can see, those instructions (appearing 18 times in the input code), are used zero times in the output code. These instructions cannot be related because they are never compiled in this configuration.
I'm not sure what you mean. I use OpenWatcom V2 for this code, and it works just fine. I even included screenshots and the compiled binaries. It is, in fact, the primary compiler used for building G on MS-DOS and OS/2. |
|
None of that code is relevant - it is not used at all when you compile G for DOS as I've shown above - you can confirm this by looking at OpenWatcom's C preprocessor output. OpenWatcom compiles G just fine. The only issue is that the 8086 EXE (compiled with -0) misbehaves. Using -1 or anything else, the problem goes away. |
|
Sorry you are ignoring what I tried to explain you, your OW in-line code is buggy. |
You are not understanding me. I am NOT ignoring you. Not at all. You seem to be missing the fact the code you are talking about is not used at all. Again, it is not even compiled as part of the binary that is causing the problem. You can simply remove it - since it is not compiled, it cannot matter. Please look at the exact commands I'm running above, with unedited output. In fact, I'll create a branch with all that code removed but the problem remains ... |
|
I've removed all that code, and the binary which OpenWatcom produces is identical, which confirms that it's impossible that code could be a problem, as it is never compiled. This doesn't help or change anything, unfortunately. Compiling this revised code, with all that removed, gives me the exact binary with the exact same problems: -rwxr-xr-x 1 jhj jhj 116170 May 9 06:52 g86.exe
-rw-r--r-- 1 jhj jhj 116170 May 9 05:13 g86-old.exe(Edit: Use the https://github.com/johnsonjh/g/blob/asm2/src/g.c file, as I kind of botched the commit referenced above.) |
|
See https://github.com/johnsonjh/g/blob/asm2/src/g.c for the preprocessed version of the code. You can see, there are no assembly instructions at all. I compiled it again with: I compiled with Again, I think you are misunderstanding the problem I'm trying to report. There is no problem compiling this code. It's only running the binaries. The binary compiled with Edit: These binaries are the same as the ones in #862 (comment) but feel free to try to reproduce. |
I'm aware - it's impossible to even compile that code for 8086. The code you are talking about is never used, except when building for 386+ CPU's, and is then only enabled with |
|
I don't want study your code. |
|
Anyway your code is terrible. what about C and POSIX standards for TINY_G must be defined as and condition must be Using of OW in-line code your way is terrible, mixture of 32-bit CPU and 16-bit CPU instruction for 16-bit DOS code etc. without any condition. |
|
This code compiles just fine - I actually support multiple DOS extenders - but that's besides the point here. None of this code is even compiled or present in the binaries in question. You really need to understand this to be able to help me. Once again, you MUST be getting confused I think, because the code you are mentioning is not used in any extended DOS configuration. It's used ONLY in real-mode 386 configurations. But, just to show you, OpenWatcom V2 has zero issues at all with this code. Here is a 32-bit DOS32/A version: I regularly build DJGPP versions as well, no problems. I simply cannot understand why you say this cannot compile? Not only does it compile, but the 32-bit DOS extender versions are the ones I use daily. I've even attached the compiled DJGPP and OpenWatcom V2 DOS extended versions to this post. You don't even have to believe me here. You can replicate my compiles in less than 10 seconds using a fresh checkout of the git repo! OpenWatcom V2 DOS32/A 32-bit build: g386p.exe.gz I really need you believe the code compiles. I'm very very frustrated here, because this code compiles just fine on literally every system I've tried it on. I mean, my mind is blown here. I'm not trying to be obstinate, but what you are telling me has no bearing whatsoever on reality! Here is a VIDEO of me compiling G just fine using a DOS extender as above - it takes literally seconds: Here is the unedited video proof that it compiles and runs and using a 32-bit DOS extender ... G-DOS.mp4However, none of this is remotely related to the problem!!!! |
|
I've actually worked to try narrow down the problem and I've been able to narrow it down very much. The problem happens only when using If I don't use If I use Here is a video of the entire process from a fresh git checkout. In the first 60 seconds, I build G for MS-DOS 8086 WITH In the final 60 seconds, I demonstrate that the ZM-problem.mp4 |
I removed this, but it doesn't fix anything. Here is video proof of removing it and the problem 100% remains. When I change the compilation to remove The following 100 second video shows proof of the broken build even with that code removed, and shows that removing ZM-OWC2.mp4 |
|
It is your problem with your code, not my. |
|
Did you even watch the video? The problem is I showed you video proof of this. I can't understand what our disconnect is here! I don't care if you close the issue out, but I want to understand the problem. I did exactly what you said fixes the problem. It does not fix the problem. I made a video of myself doing this. How is this a bug in G? I did exactly as you said and the problem remains. If the problem is a bug in this code, how can the bug remain in the code when the code you said was buggy has been removed and no longer exists? I'm not trying to be difficult here. I really want to understand how deleted code can affect this? Forget EVERYTHING else:
Please - I'm really trying to understand here! I did exactly the fix you suggested and the fix you claimed work and you say it doesn't work?! I feel like I'm going insane here. :( |
johnsonjh
changed the title
-zm - was: Miscompilation when using (-0) 8086 real-mode DOS target, working for (-1) 80186 higher targets
|
Regardless, feel free to leave it closed. I won't use |
|
Now you are really going to hate me. I cannot replicate the problem at all using the OpenWatcom V2 build from 2022-05-05. I was using 2022-03-13. So, for anyone who happens to care or have a similar issue upgrading to 2022-05-05 made the problem go away without other changes. |
… issues - at least for me - with 8086 builds. The OpenWatcom V2 upstream claims they could not replicate it, however. (open-watcom/open-watcom-v2#862) - While here, removed the old and now unused mini-crt0.asm and associated code to avoid further confusion from anyone thinking it was in use, that was for old WATCOM versions only - removed references to the mini-crt0 from the documentation as well. Closes #16
I'm having a bit of trouble building an 8086 version of the G editor for DOS.
(TL;DR - Exact same code broken using
-0, and OK with-1)I regularly build G with many compilers (new and old), but it had been very a long time (~1995) since the DOS ports had been regularly compiled, since I took up maintaining it. (The output of my
make testscript is available here if you'd like to see exactly how each variant is built.)This test script does not automate all possible DOS builds, such as those using MS-DOS based compilers, however, I can confirm that 8086 binaries built with Microsoft C 7.00b, Microsoft C 8.00a (MSVC 1.52c), and Borland C 5.02 work as expected, with no issues. (Unrelated, but just a note to anyone looking into this, the IA16-GCC builds done by this testing script aren't working yet; this is due to the lack of a large memory model in that compiler).
Since the Microsoft C builds work, and are also smaller, I'm currently using Microsoft C to produce the reference binaries available for download; these can be used to double-check the correct behavior, since they are quite extensively tested.
To build the (unusable) 8086 binary using OpenWatcom v2, I use the following:
Once compiled, the quickest way to identify a bad build is to load a file from the command line, and then attempt to save it using
F7, producing the following result:Rebuilding exactly as above, but using
-1instead of-0results in a compiled binary that works fine:Pressing
F7works exactly as expected:Note that the problems aren't limited to
F7to save - the editor is completely unusable using-0, and perfectly fine with-1.Compiler version:
I've tried a slightly newer build but still had the same problems - I haven't yet been able to update to a "0-day" version. I hope this helps in tracking down the problem.
The text was updated successfully, but these errors were encountered: