From: nisse@lysator.liu.se (Niels Möller) Cc: nettle-bugs@lists.lysator.liu.se Date: Fri, 30 May 2014 15:57:40 +0200
=>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()
I don't use wine, so I don't know what that means.
[/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) .
Sounds like infinite recursion?
Is it possible for you to do a git checkout?
Yes.
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.
OK, I'll see what I can find out.
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
Hard to say what's going on here, as too many non-native tools are involved.
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?
The only thing I'd expect is a call through an indirect address, since you are linking to a DLL. But the above doesn't look like that.
The message seemed to say that the latter case won't work with auto import, but maybe I misunderstood it.
I'll look into it.