#3797 Regression test failures with 32-bit Windows build in nativecrosstools branch

[Philipp Klaus Krause]

Having build SDCC for 32-bit Windows using the current nativecrosstools branch, I get:

Summary for 'ds390': 0 failures, 27753 tests, 6000 test cases, 26383157 bytes, 4545447768 ticks
Summary for 'mcs51-medium': 0 failures, 23496 tests, 5995 test cases, 11581507 bytes, 1637405928 ticks
Summary for 'mcs51-small-stack-auto': 0 failures, 24461 tests, 5995 test cases, 11286594 bytes, 1027202400 ticks
Summary for 'hc08': 11 failures, 32524 tests, 6000 test cases, 9750986 bytes, 373395249 ticks
Summary for 'ucz80': 2 failures, 32450 tests, 6003 test cases, 7522953 bytes, 1013115330 ticks
Summary for 'ez80-z80': 1 failures, 32333 tests, 6003 test cases, 7327860 bytes, 871165453 ticks
Summary for 'ucr800': 2 failures, 32298 tests, 6005 test cases, 7549583 bytes, 263759446 ticks
Summary for 'ucr2ka': 1 failures, 32377 tests, 6003 test cases, 7437026 bytes, 443795881 ticks
Summary for 'stm8-large': 10 failures, 32441 tests, 6005 test cases, 6279745 bytes, 103718671 ticks
Summary for 'pdk15-stack-auto': 3 failures, 13041 tests, 5941 test cases, 9147102 bytes, 171995513 ticks
Summary for 'uc6502': 0 failures, 32526 tests, 6002 test cases, 9678022 bytes, 339317671 ticks
Summary for 'mcs51-small': 0 failures, 23849 tests, 5990 test cases, 9950853 bytes, 816614208 ticks
Summary for 'mcs51-large-stack-auto': 0 failures, 26169 tests, 5997 test cases, 12797246 bytes, 1661529048 ticks
Summary for 's08': 9 failures, 32525 tests, 6000 test cases, 9043315 bytes, 356307415 ticks
Summary for 'ucz80-resiy': 2 failures, 32451 tests, 6003 test cases, 7368304 bytes, 1000165220 ticks
Summary for 'ucz180': 1 failures, 32401 tests, 6003 test cases, 7558771 bytes, 1013953515 ticks
Summary for 'ucz80-undoc': 1 failures, 32450 tests, 6003 test cases, 7525129 bytes, 1010119869 ticks
Summary for 'ucz80-unsafe-read': 2 failures, 32450 tests, 6003 test cases, 7523408 bytes, 1012921125 ticks
Summary for 'ucr2k': 1 failures, 32377 tests, 6003 test cases, 7443894 bytes, 457844866 ticks
Summary for 'stm8': 6 failures, 30466 tests, 6005 test cases, 5903124 bytes, 97676630 ticks
Summary for 'pdk15': 1 failures, 17257 tests, 5943 test cases, 4488468 bytes, 57042723 ticks
Summary for 'uc65c02': 0 failures, 32526 tests, 6002 test cases, 11066363 bytes, 351231055 ticks
Summary for 'mcs51-large': 0 failures, 26187 tests, 6000 test cases, 13368343 bytes, 2222276460 ticks
Summary for 'mcs51-huge': 0 failures, 26187 tests, 6000 test cases, 15110381 bytes, 2492559084 ticks
Summary for 's08-stack-auto': 0 failures, 32252 tests, 5998 test cases, 9931673 bytes, 398395425 ticks
Summary for 'ucz80n': 1 failures, 32397 tests, 6003 test cases, 7506078 bytes, 983464176 ticks
Summary for 'ucz180-resiy': 1 failures, 32401 tests, 6003 test cases, 7391760 bytes, 968345487 ticks
Summary for 'ucgbz80': 4 failures, 32299 tests, 6003 test cases, 7803187 bytes, 1332058665 ticks
Summary for 'tlcs90': 0 failures, 32316 tests, 6003 test cases, 8276591 bytes, 575640386 ticks
Summary for 'ucr3ka': 1 failures, 32377 tests, 6003 test cases, 7392461 bytes, 438375522 ticks
Summary for 'pdk14': 1 failures, 11701 tests, 5933 test cases, 2527159 bytes, 24929670 ticks

So, essentially, there is a small number of failures for each port except mcs51 and ds390, the two ports that still use the old register allocator.

[Philipp Klaus Krause]

Looking into one of the failures (bug-2684.c) I see:

sdcc-builder@notebook6:~/build/sdcc-build/i686-w64-mingw32.build/sdcc/support/regression$ wine sdcc --fverbose-asm -DNO_VARARGS -I/home/sdcc-builder/build/sdcc-build/orig/sdcc -mz80 --less-pedantic -I/home/sdcc-builder/build/sdcc-build/orig/sdcc/support/regression/fwk/include -I/home/sdcc-builder/build/sdcc-build/orig/sdcc/support/regression/tests -I/home/sdcc-builder/build/sdcc-build/orig/sdcc/device/include -c cases/tst_bug-2684.c -o gen/ucz80/tst_bug-2684.rel
008c:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
008c:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."
008c:err:systray:initialize_systray Could not create tray window
Caught signal 11: SIGSEGV

So the sdcc.exe installed by our installer segfaults. Not the snapshot build process build non-stripped and stripped versions of sdcc.exe. The one that segfaults is a stripped one. Let's try the stripped one that was built for the snapshot:

sdcc-builder@notebook6:~/build/sdcc-build/i686-w64-mingw32.build/sdcc/support/regression$ wine ~/build/sdcc-build/build/i686-w64-mingw32/sdcc/sdcc/bin/sdcc.exe --fverbose-asm -DNO_VARARGS -I/home/sdcc-builder/build/sdcc-build/orig/sdcc -mz80 --less-pedantic -I/home/sdcc-builder/build/sdcc-build/orig/sdcc/support/regression/fwk/include -I/home/sdcc-builder/build/sdcc-build/orig/sdcc/support/regression/tests -I/home/sdcc-builder/build/sdcc-build/orig/sdcc/device/include -c cases/tst_bug-2684.c -o gen/ucz80/tst_bug-2684.rel
0094:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
0094:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."
0094:err:systray:initialize_systray Could not create tray window

No segfault. So what is the difference?

sdcc-builder@notebook6:~$ cmp -l build/sdcc-build/build/i686-w64-mingw32/sdcc/sdcc/bin/sdcc.exe .wine/"drive_c/Program Files (x86)/SDCC/bin/sdcc.exe"
    137 164  27
    217  75 340
    218 311 310

Three byte differ (positions 137, 217 and 218) between the sdcc.exe as built, and the sdcc.exe as installed (cmp counts bytes starting at 1, and gives the value of the bytes in octal).

But if I copy the non-segfaulting sdcc.exe to the location of the segfaulting one, I again get the segfault. And it still segfaults, when I give wine the full path. And the non-stripped sdcc.exe segfaults when in that location, too (ok, I guess that will help me with debugging).

[Janko Stamenović]

It seems to me that these locations, if they are really the only difference, are in the area commonly referred to as PE header. Maybe to compare what's there different you can try to use:

objdump  -x sdcc1.exe >sdcc1.exe.txt
objdump  -x sdcc2.exe >sdcc2.exe.txt

and then diff these two.