Dragonegg miscompiles dlls/crypt32/message.c from wine

[llvmbot]

Bugzilla Link	10639
Version	2.9
OS	Linux
Blocks	llvm/llvm-bugzilla-archive#10682
Attachments	llvm-preprocessed file, preprocessed gcc file
Reporter	LLVM Bugzilla Contributor

Extended Description

Dragonegg can compile wine successfully, aside from http://bugs.winehq.org/show_bug.cgi?id=28050. Running its test suite, however, shows a few problems. This is the first one (8 potential).

To reproduce, compile wine with:
$ CC=llvm-gcc ./configure
$ make

then run the test:
$ cd dlls/crypt32/tests
$ make message.ok

this will fail:
austin@debian:~/wine-llvmgcc/dlls/crypt32/tests$ make message.ok
../../../tools/runtest -q -P wine -M crypt32.dll -T ../../.. -p crypt32_test.exe.so message.c && touch message.ok
message.c:1079: Test failed: unexpected value
message.c:1097: Test failed: unexpected value
message.c:1116: Test failed: unexpected value
message.c:1138: Test failed: unexpected value
message.c:1167: Test failed: unexpected value
message.c:1190: Test failed: unexpected value
make: *** [message.ok] Error 6

compilings crypt32/message.c with gcc, or using -O0 instead works around the issue. I'll attach preprocessed source files from llvm-gcc and gcc (versions below). If more info is needed, please don't hesitate to ask.

austin@debian:~/wine-llvmgcc/dlls/crypt32/tests$ llvm-gcc --version
gcc-4.5 (Debian 4.5.3-3) 4.5.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

austin@debian:~/wine-llvmgcc/dlls/crypt32/tests$ gcc --version
gcc (Debian 4.4.6-7) 4.4.6
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[llvmbot]

Files were made with:

llvm-gcc -E -I. -I. -I../../include -I../../include -D__WINESRC__ -D_CRYPT32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O1 message.c -o message.s

gcc -E -I. -I. -I../../include -I../../include -D__WINESRC__ -D_CRYPT32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O1 message.c -o message_gcc.s

[llvmbot]

I took a look at this using latest LLVM and dragonegg from svn. If you want
to do the same you will need to apply this patch to dragonegg to work around
LLVM bug 10641:

Index: src/Constants.cpp

--- src/Constants.cpp (revision 137305)
+++ src/Constants.cpp (working copy)
@@ -1035,8 +1035,8 @@
// last elements of the constant, maybe yielding something less horrible.
C = getAsBits();
Starts = R.getFirst();

• if (isSafeToReturnContentsDirectly(TD))

•  return C;
  

+// if (isSafeToReturnContentsDirectly(TD))
+// return C;
// The integer type used to hold the bits was too big (for example an i24
// typically occupies 32 bits so is too big for a range of 24 bits). Turn
// it into an array of bytes instead.

The problem described in http://bugs.winehq.org/show_bug.cgi?id=28050 is still
present.

The bad news is that running this test results in what looks like major
failures, much worse than you described. I get winedbg windows popping up
all over the place any much unhappiness. This is with wine 1.27.

So it looks like there have been some major regressions. I think the best thing
to do is for you to also build wine with latest LLVM/dragonegg, and try to find
the simplest case of something failing. With the current situation I hardly
know where to start.

See http://dragonegg.llvm.org for help on building the development version.

[llvmbot]

Tried compiling dragonegg on debian testing, but haven't been successful. The farthest I got was http://pastebin.com/RbnXFP4i. I'm idling in #llvm now, but you're not there, and no one else seems to know the solution :).

[llvmbot]

Hi, don't use CFLAGS like this. If the GCC you want to use the plugin with is
called (for example) gcc-4.5 then build like this:
GCC=gcc-4.5 make
If this gcc-4.5 is one supplied by Debian (rather than one you built yourself)
then you will need to
(1) Install the gcc-4.5-plugin-dev package:
apt-get install gcc-4.5-plugin-dev
(2) Build using the development versions of dragonegg and LLVM from subversion. That's because dragonegg-2.9 requires a patched version of gcc, which means having to build gcc yourself. The development version doesn't require patching gcc, so can be built against a standard Debian gcc (gcc-4.5 or gcc-4.6), though as I mentioned you do need to install gcc-4.5-plugin-dev.

[llvmbot]

Hi, don't use CFLAGS like this. If the GCC you want to use the plugin with is
called (for example) gcc-4.5 then build like this:
GCC=gcc-4.5 make
If this gcc-4.5 is one supplied by Debian (rather than one you built yourself)
then you will need to
(1) Install the gcc-4.5-plugin-dev package:
apt-get install gcc-4.5-plugin-dev
(2) Build using the development versions of dragonegg and LLVM from
subversion. That's because dragonegg-2.9 requires a patched version of gcc,
which means having to build gcc yourself. The development version doesn't
require patching gcc, so can be built against a standard Debian gcc (gcc-4.5 or
gcc-4.6), though as I mentioned you do need to install gcc-4.5-plugin-dev.

Thanks, I had plugin-dev installed, but GCC=/usr/bin/gcc-4.5 make failed, as did plain make. GCC=gcc-4.5 make worked though.

After that, I applied your patch from comment #​1, and compiled wine with:
CC="gcc-4.5 -fplugin=/home/austin/src/dragonegg/dragonegg.so" ./configure
make

and ran 'make test'. The first failure was again crypt32/tests/message.c, but it failed in the same way as before.

[llvmbot]

One annoyance when looking into this was that the wine debugger popped up many
times (presumably each time a test failed?), and since the wine debugger isn't
working properly either it would crash. The final result: an impossible to get
rid of sequence of debug windows. Is there any way to arrange for the wine
debugger to not be activated on failure?

[llvmbot]

One annoyance when looking into this was that the wine debugger popped up many
times (presumably each time a test failed?), and since the wine debugger isn't
working properly either it would crash. The final result: an impossible to get
rid of sequence of debug windows. Is there any way to arrange for the wine
debugger to not be activated on failure?

http://wiki.winehq.org/UsefulRegistryKeys

To disable the dialog, add this registry key:
[HKEY_CURRENT_USER\Software\Wine\WineDbg]
"ShowCrashDialog"=dword:00000000

you can also disable break on first chance, which may help:
[HKEY_CURRENT_USER\Software\Wine\WineDbg]
"BreakOnFirstChance"=dword:00000000

[llvmbot]

mentioned in issue #11054

[asl]

Dragonegg is obsolete