WASM crashes when exporting one or more floating point fixup entries.

[agatti]

Defining and exporting one or more of FIDRQQ, FIWRQQ, FIERQQ, FIARQQ, FISRQQ, FICRQQ, FJERQQ, FJARQQ, FJSRQQ, FJCRQQ, and FIXRQQ and using any floating point opcode makes WASM crash.

For example, this small assembly file (also attached to this report) when assembled with "Open Watcom x86 Assembler Version 2.0 beta Feb 9 2024 20:16:48 (64-bit)" (coming out of Arch Linux's AUR repository):

        .MODEL  SMALL

        .8087

        PUBLIC  FIDRQQ

FIDRQQ          EQU     05C32H

_TEXT   SEGMENT "CODE"

code:

        fstp    st(2)
        fstp    st(3)
        ret     0

_TEXT   ENDS

        END

triggers the following crash:

Reading symbols from /opt/watcom/binl64/wasm...
Reading symbols from /opt/watcom/binl64/wasm.sym...
Core was generated by `/opt/watcom/binl64/wasm bug.asm'.                                                                                                                                     
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000405265 in CreateFixupRec (fixup=0x17d2690, offset=0) at ../c/write.c:862
Downloading source file /home/runner/work/open-watcom-v2/open-watcom-v2/bld/wasm/linuxx64/../c/write.c                                                                                                                                                                                             
warning: 862    ../c/write.c: No such file or directory
(gdb) bt
#0  0x0000000000405265 in CreateFixupRec (fixup=0x17d2690, offset=0) at ../c/write.c:862
#1  get_fixup_list (fl32=<synthetic pointer>, fl16=<synthetic pointer>, start=0) at ../c/write.c:891
#2  write_ledata () at ../c/write.c:997
#3  FlushCurrSeg () at ../c/write.c:1123
#4  0x000000000040938c in SetCurrSeg (tokbuf=tokbuf@entry=0x7ffd124ea910, i=i@entry=1 '\001') at ../c/direct.c:1455
#5  0x000000000041313b in directive (tokbuf=tokbuf@entry=0x7ffd124ea910, i=<optimized out>, direct=T_ENDS) at ../c/breakout.c:196
#6  0x0000000000418fb8 in AsmParse (tokbuf=tokbuf@entry=0x7ffd124ea910, curline=curline@entry=0x7ffd124eb830 "_TEXT\tENDS") at ../c/asmins.c:2525
#7  0x000000000041baca in AsmLine (string=string@entry=0x7ffd124eb830 "_TEXT\tENDS") at ../c/asmline.c:741
#8  0x0000000000404bad in OnePass (string=string@entry=0x7ffd124eb830 "_TEXT\tENDS") at ../c/write.c:1195
#9  0x000000000040604a in WriteObjModule () at ../c/write.c:1271
#10 0x0000000000403be1 in main (argc=<optimized out>, argv=0x7ffd124ec268) at ../c/main.c:1184

Attachments:

bug.txt

[jmalak]

for which target do you compile it? could you give here wasm and linker full command lines. what host system you use?

[jmalak]

Anyway these symbol cannot be in custom code. They are handled by assembler in dependency on -fpi or -fpi87 options and generate appropriate fixups.

[jmalak]

Proper source code is

        .MODEL  SMALL

        .8087

_TEXT   SEGMENT "CODE"

code:
        fstp    st(2)
        fstp    st(3)
        ret     0

_TEXT   ENDS

        END

and compiled and disassembled code is

                EXTRN   FIDRQQ:BYTE
DGROUP          GROUP   _DATA
_TEXT           SEGMENT WORD PUBLIC USE16 'CODE'
                ASSUME CS:_TEXT, DS:DGROUP, SS:DGROUP
        fstp            st(2) ; int 39H
        fstp            st(3) ; int 39H
        ret             0
_TEXT           ENDS
_DATA           SEGMENT WORD PUBLIC USE16 'DATA'
_DATA           ENDS
                END

[agatti]

@jmalak The command line was simply "/opt/watcom/binl64/wasm bug.asm", targetting real mode x86 (also shows up in GDB's messages). I'm running OW on a plain x64 Arch Linux system.

I understand I'm doing something I shouldn't really do myself, but I'm exporting the whole lot manually as other code/compiler (TopSpeed C) I'm interfacing with seems to expect the whole set of FPU fixups being exported rather than only the fixups needed to link the object generated by OW. For the moment I'm using TopSpeed's linker, not OW's, although I plan to fully migrate to OW for this.

Still, an error message would be nicer than a crash, wouldn't it? :)

[jmalak]

yes, it should not crash. But the code is nonsense. These fixups are only for FPU emulator, if you want native FPU code then use -fpi87 wasm option.

[agatti]

Yep, and I'm in fact writing FPU emulation code...

[jmalak]

OW has FPU emulator that you can use it or modify it for your run-time environment.

[agatti]

Right, but I'm not sure it would solve my problem. I'm fixing bugs in the FPU emulator for an embedded system for which I have to maintain compatibility at both the binary and numerical level, and still be able to link everything on a late 1980s compiler. I'm modifying the disassembled code for the platform's FPU emulator (it's not even TopSpeed's), so I cannot really use OpenWatcom's FPU emulator.

If there is no chance for WASM to let me redefine those symbols myself I can always postprocess the generated object file and put those OMF records in myself and keep TopSpeed's linker happy, but I'm trying to avoid to add extra complexity if I can. If that's the case then feel free to close this bug.

Still, thanks for your time!

[jmalak]

you can redefine them no problem, but you cannot do it your way. Below is code how you can define it in separate module.

.8087
public  FJSRQQ
FJSRQQ  equ             08000H
public  FISRQQ
FISRQQ  equ             00632H
public  FIERQQ
FIERQQ  equ             01632H
public  FIDRQQ
FIDRQQ  equ             05C32H
public  FIWRQQ
FIWRQQ  equ             0A23DH
public  FJCRQQ
FJCRQQ  equ             0C000H
public  FJARQQ
FJARQQ  equ             04000H
public  FICRQQ
FICRQQ  equ             00E32H
public  FIARQQ
FIARQQ  equ             0FE32H

[agatti]

Thanks @jmalak, I'll try to export those symbols that way and see if TopSpeed's linker doesn't complain about them being in a different unit. If that's not enough, well, I'll merge the OMF records myself but that's another matter.

Do you still want to keep this bug open to track the WASM crash or should I close it?

[jmalak]

We will hold it open, to be fixed in next wasm review. Anyway problem is with combination of FPU code and definition of these symbols in single module due to WASM bug. !!! important, you must assembly this module with -fpc wasm option. !!!

[jmalak]

the problem should be fix, now FP fixup symbols used by wasm are separated from user symbol space therefore user symbol can be any type not related to type of FP fixup symbol used by wasm symbol defined in user symbol space is as other symbols and wasm doesn't use it for FP fixup as before

[agatti]

Thank you @jmalak, I'll give it a try once the Arch Linux AUR package picks up the latest snapshot with this fix in.

[jmalak]

you need not wait for it. You can download current OW build snapshot archive and extract it somewhere and pickup wasm executable only and replace it on your box file-by-file, only be careful with executable bit on Linux (archive tar file contain it)

[agatti]

It's ok, the AUR package picked the new snapshot up. I can confirm that it doesn't crash anymore. Thanks!

[jmalak]

Thank you for your confirmation. Now it generate proper code for your original code, that you can use it without change.