Eli Zaretskii eliz@gnu.org writes:
Why the "msvc" suffix? I think it shouldn't be there. (Not that I think this necessarily has any relevance to your problem.)
Only because the debian mingw32 package uses names like "i586-mingw32msvc-gcc" for cross-compiler and related tools.
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.
Right, I understand it's an access at an invalid address. Some things that are unclear to me: The meaning of the second address in "=>0 0x70dc344d (0x0061fdc8)". And why "test_main+0x36() [/home/nisse/hack/nettle/testsuite/arcfour-test.c:73]" occurs a large number of times in the backtrace. I quoted just the first two above, but it's 200 such lines, with only the value in the last parentheses differing between lines (and 0x00000000 in all but the first 10 lines) .
- 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.
I think it would be interesting both to test native compilation, and to test the cross compiled arcfour-test.exe and libnettle.dll on a w32 machine.
Is it possible for you to do a git checkout?
For the cross-compile case, it would be
git clone git://git.lysator.liu.se/nettle/nettle.git cd nettle ./.bootstrap ./configure --host=i586-mingw32msvc make make -C testsuite arcfour-test.exe
and then copy .lib/libnettle-5-0.dll and testsuite/arcfour-test.exe to the windows test machine.
For native compile, instead ./configure && make dist to produce a tarball.
- 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.
Ok, the assembly code is intended to use the plain cdecl convention.
I'm really puzzled. If I use i586-mingw32msvc-objdump to disassemble arcfour-test.exe, the call to nettle_arcfour_crypt looks like
4014e7: 53 push %ebx 4014e8: 50 push %eax 4014e9: e8 b2 6c 00 00 call 4081a0 <__imp__nettle_arcfour_crypt>
004014ea <__fu0__nettle_arcfour_crypt>: 4014ea: b2 6c mov $0x6c,%dl 4014ec: 00 00 add %al,(%eax) 4014ee: 8b 95 d8 fe ff ff mov -0x128(%ebp),%edx
Looks sane to me.
However, when I run it in gdb (I inserted an asm volatile("int $3") in the C code, and then I run native gdb on the wine.bin ELF-binary, and give wine the arcfour-test.exe file as argument), and disassemble the code, the address is different,
Dump of assembler code from 0x4014e9 to 0x4014fd: => 0x004014e9: call 0x70dc347e 0x004014ee: mov -0x128(%ebp),%edx 0x004014f4: add $0x20,%esp 0x004014f7: cmpb $0x17,(%esi,%edx,1) 0x004014fb: jne 0x401655
If I also dump the machine code for the call instruction it's
e8 90 1f 9c 70
So this has somehow been relocated when the .exe file was loaded by wine, and relocated incorrectly to point into nowhere. I'm not really sure what the instruction format is, but isn't it pc-relative addressing? Or is relocation expected here?
And it's fetching the next instruction, at address 0x70dc347e, that results in an invalid memory access. So it's before it gets to the implementation of nettle_arcfour_crypt, which makes it even more puzzling that the implementation language seem to matter. Maybe I need some special pseudo-ops in the assembly file to get it to be linked correctly as part of a dll?
So this could be some bug in my assembly code, or problem with the cross tools or the way I invoke them, or a bug in wine.
Was the code compiled with or without optimizations? If the former, some arguments might be in registers, not on the stack.
arcfour_crypt is in it's own source file, either .c or .asm. So it ought to always use the same "cdecl" convention. And it breaks only when the assembly file is used.
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.)
I have some structures (but not in the arcfour-test program with function pointers). Both in the library, e.g, const struct nettle_hash nettle_md5, and in the application, e.g, const struct nettle_aead nettle_arcfour128 (defined in nettle-internal.c, and linked into the nettle-benchmark executable). Both structs include function pointers to functions defined in the shared library.
The message seemed to say that the latter case won't work with auto import, but maybe I misunderstood it.
Regards, /Niels