> From: [email protected] (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. > 1. 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. > 2. 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.) _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
