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