Eli Zaretskii <[email protected]> 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) .
>> 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.
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.
>> 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.
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
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
