lerdmann
commented
9 months ago I have a trap dump that hopefully illustrates the problem. To explain, FXWRAP.SYS contains 4 segments, 1. segment is the default data segment, 2. segment is the code segment, 3. segment is the "MAC_QUEUE" data segment and 4. segment is the "PROT_QUEUE" data segment. When I use the _based keyword with Watcom 1.9, I get this:
.lmo 29d hmte=029d pmte=%fc23eeb0 mflags=0100f1c1 d:\ibmcom\protocol\fxwrap.sys seg sect psiz vsiz hob sel flags 0001 0001 05a6 05a6 0000 2d58 8d41 data prel rel 0002 0005 2bf6 2bf6 0000 2d60 ad60 code shr prel rel 0003 001c fea4 fea4 0000 dd2f 0c01 data 0004 009c fea4 fea4 0000 dd27 0c01 data dg 2d58 2d58 Data Bas=fbfeb30c Lim=000005a3 DPL=0 P RW A dg 2d60 2d60 Code Bas=fbbe9000 Lim=00002bf2 DPL=0 P RE A dg dd2f LDT dd2f Data Bas=1ba50000 Lim=0000fea3 DPL=3 P RW A dg dd27 LDT dd27 Data Bas=1ba40000 Lim=0000fea3 DPL=3 P RW A
As can be seen, the 3. and 4. segment are created as DPL=3 segments in the LDT instead of DPL=0 segments in the GDT. Of course, as soon as the driver accesses these segments, the system traps.
If instead, I let this run through the Watcom 2.0 compiler I get this: .lmo 29c
hmte=029c pmte=%fc23ce68 mflags=0100f1c1 d:\ibmcom\protocol\fxwrap.sys seg sect psiz vsiz hob sel flags 0001 0001 05aa 05aa 0000 2d50 8d41 data prel rel 0002 0005 2df6 2df6 0000 2d58 ad60 code shr prel rel 0003 001d fea4 fea4 0000 2d60 8c41 data prel 0004 009d fea4 fea4 0000 2d68 8c41 data prel dg 2d50 2d50 Data Bas=fc233724 Lim=000005a7 DPL=0 P RW A dg 2d58 2d58 Code Bas=fbbea000 Lim=00002df2 DPL=0 P RE A dg 2d60 2d60 Data Bas=fa855000 Lim=0000fea3 DPL=0 P RW dg 2d68 2d68 Data Bas=fa865000 Lim=0000fea3 DPL=0 P RW
as expected (all segments have DPL = 0 and all descriptors are located in the GDT).
I am using these versions: open-watcom-c-os2-1.9.exe and open-watcom-2_0-c-os2_20221118.exe I cannot remember where I got the watcom-c-os2-1.9.exe from.
That said it might also be a linker problem rather than a compiler problem but I would think that the compiler adds segment fixups and offset fixups to the object files or does the linker do that ?
As a very wild ass guess, it might have to do with this change added by Juri to the Watcom 2 (fixing my problem):
https://github.com/open-watcom/open-watcom-v2/commit/e905d92c6d3b5b7c22845e4450bd9a7ba5b87757
The workaround was to use the #pragma data_seg directive under Watcom 1.9 which gives the desired result but Jiri in his infinite wisdom removed that from Watcom 2.0.
When we build injoy with the following addition and OW 1.9 the driver traps. While with OW 2 it works. It seems like a base ptr issue. For now we added a ifdef to overcome it. `
if (WATCOMC >= 1300) // special treatment for Watcom 2.0 and above
pragma message("Compiling with Watcom 2.0 or above !")
extern char _based(_segname("MAC_QUEUE")) cPktBuffer1[QUEUE_DEPTH]; extern char _based(_segname("PROT_QUEUE")) cPktBuffer2[QUEUE_DEPTH];
else
pragma message("Compiling with Watcom 1.9 or below !")
extern char far cPktBuffer1[QUEUE_DEPTH]; extern char far cPktBuffer2[QUEUE_DEPTH];
endif
` While investigating I found 2 commits in jiri his repo, which might be the fixes. But im not a compiler pro https://github.com/open-watcom/open-watcom-v2/commit/1190b9bcb39895eb4e080a0c0b92e6c66669c9c1 https://github.com/open-watcom/open-watcom-v2/commit/ef633cf82cecf192b251d4fb1675e98ee0e68c17