From: nisse@lysator.liu.se (Niels Möller) Date: Fri, 30 May 2014 12:02:08 +0200
I just tested w32 support,
./configure --host=i586-mingw32msvc
Why the "msvc" suffix? I think it shouldn't be there. (Not that I think this necessarily has any relevance to your problem.)
which produces shared libraries (and I'm not sure I've tested this eariler, I may have used --disable-shared on earlier builds for w32).
When I run the testsuite with make check EMULATOR=wine, the arcfour testcase fails. wine reports the error like
Unhandled exception: page fault on read access to 0x70dc344d in 32-bit code (0x70dc344d). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:70dc344d ESP:0061fc5c EBP:0061fdc8 EFLAGS:00010202( R- -- I - - - ) EAX:0061fcba EBX:00000001 ECX:00000001 EDX:00000001 ESI:001139ef EDI:001139b0 Stack dump: 0x0061fc5c: 004014bd 0061fcba 00000001 001139f0 0x0061fc6c: 001139b0 0061fcd0 7bc4abf6 00000001 0x0061fc7c: 00113990 001139f8 001139b0 001139d0 0x0061fc8c: 00000000 00000000 00113988 001139a8 0x0061fc9c: 001139c8 00000008 00000009 001139f0 0x0061fcac: 7bc3812f 00000020 0061fcc8 df019956 Backtrace: =>0 0x70dc344d (0x0061fdc8) 1 0x00401767 test_main+0x36() [/home/nisse/hack/nettle/testsuite/arcfour-test.c:73] in arcfour-test (0x0061fde8) 2 0x00401767 test_main+0x36() [/home/nisse/hack/nettle/testsuite/arcfour-test.c:73] in arcfour-test (0x0061fe08)
I'm not entirely sure how to interpret this
It's the equivalent of a SIGSEGV, but I'm sure you know that.
- Can the problem be reproduced on a M$ windows machine?
If you tell which tarball to download and how to configure and build it, I can try reproducing this in a native build.
- Are there any calling convention subtleties in dll calls?
What do you mean by "dll calls"? Do you mean calling functions that are in a DLL? If so, they go through an indirect call in the import library, but other than that, they use the normal "cdecl" calling convention.
I just push and pop the callee-save registers %ebx, %ebp, %esi, %edi, and read the arguments from the stack.
Was the code compiled with or without optimizations? If the former, some arguments might be in registers, not on the stack.
I have no dllimport/dllexport stuff in the header files, instead relying on mingw tools doing the right thing automatically. I get lots of messages like
Info: resolving _nettle_arcfour_crypt by linking to __imp__nettle_arcfour_crypt (auto-import) /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/bin/ld: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.
This is normal, and shouldn't cause problems, as long as it is limited to functions (as opposed to data).
This probably needs fixing at some point
To fix that, just use the --enable-auto-import linker switch, as the message says. (Also, I think newer versions of GCC and Binutils do that automatically.)