I just tested w32 support,
./configure --host=i586-mingw32msvc
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, but it looks like the instruction pointer gets a bogus value. It looks like there's a problem with arcfoure-crypt.asm, because configuring with --disable-assembler seems to work fine. Also compiling with --disable-shared works fine.
Questions:
1. Can the problem be reproduced on a M$ windows machine?
2. Are there any calling convention subtleties in dll calls? I just push and pop the callee-save registers %ebx, %ebp, %esi, %edi, and read the arguments from 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 probably needs fixing at some point, but as far as I see, arcfour-test doesn't use any references from constant data, and it should be independent of the choice between C or assembly for arcfour-crypt.
Regards, /Niels
From: nisse@lysator.liu.se (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.
- 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.
- 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.)
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
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.
Eli Zaretskii eliz@gnu.org writes:
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.
There's some magic going on. Or lack thereof. The calling function does
4014e9: e8 b2 6c 00 00 call 4081a0 <__imp__nettle_arcfour_crypt>>
(this is from disssembling the .exe file).
And then at address 4081a0, there's
004081a0 <__imp__nettle_arcfour_crypt>: 4081a0: 98 cwtl 4081a1: 82 (bad) ...
This is not in the .text section, but in the .idata section. And in the .idata, there's
The Import Tables (interpreted .idata section contents) vma: Hint Time Forward DLL First Table Stamp Chain Name Thunk 00008000 000080b4 00000000 00000000 00008698 0000819c
DLL Name: libnettle-5-0.dll vma: Hint/Ord Member-Name Bound-To 827c 59 nettle_arcfour128_set_key 8298 60 nettle_arcfour_crypt
So it looks like the data at __imp__nettle_arcfour_crypt is not code, but the dll index 8292.
If I compare with the code I get if I configure nettle with --disable-assembler, I get a
4014b8: e8 2b 1a 00 00 call 402ee8 <_nettle_arcfour_crypt>
00402ee8 <_nettle_arcfour_crypt>: 402ee8: ff 25 34 81 40 00 jmp *0x408134 402eee: 90 nop 402eef: 90 nop
So it seems the linker does something very different (and more correct) in this case.
Regards, /Niels
From: nisse@lysator.liu.se (Niels Möller) Cc: nettle-bugs@lists.lysator.liu.se Date: Fri, 30 May 2014 21:37:39 +0200
Eli Zaretskii eliz@gnu.org writes:
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.
[...] If I compare with the code I get if I configure nettle with --disable-assembler, I get a
4014b8: e8 2b 1a 00 00 call 402ee8 <_nettle_arcfour_crypt>
00402ee8 <_nettle_arcfour_crypt>: 402ee8: ff 25 34 81 40 00 jmp *0x408134 402eee: 90 nop 402eef: 90 nop
That jmp instruction is the indirect call I was talking about. This is how the Windows loader resolves calls into a DLL. If you "stepi" into that instruction with GDB, you will find yourself inside the function in the DLL.
Eli Zaretskii eliz@gnu.org writes:
That jmp instruction is the indirect call I was talking about. This is how the Windows loader resolves calls into a DLL. If you "stepi" into that instruction with GDB, you will find yourself inside the function in the DLL.
This all makes sense. The problem is, why this doesn't happen when using the assembly version in x86/arcfour-crypt.asm. I guess I will have to compare pseudoops and symbol table attributes between working and non-working case to find out. Unless someone here already knows the answer.
Regards, /Niels
From: nisse@lysator.liu.se (Niels Möller) Cc: nettle-bugs@lists.lysator.liu.se Date: Sat, 31 May 2014 08:18:02 +0200
Eli Zaretskii eliz@gnu.org writes:
That jmp instruction is the indirect call I was talking about. This is how the Windows loader resolves calls into a DLL. If you "stepi" into that instruction with GDB, you will find yourself inside the function in the DLL.
This all makes sense. The problem is, why this doesn't happen when using the assembly version in x86/arcfour-crypt.asm.
Did you try declaring the prototype of that function with '__attribute__((dllexport))' when compiling the DLL, and with '__attribute__((dllimport)' when linking against the DLL?
Eli Zaretskii eliz@gnu.org writes:
Did you try declaring the prototype of that function with '__attribute__((dllexport))' when compiling the DLL, and with '__attribute__((dllimport)' when linking against the DLL?
No. But I think I've found a solution. I need to do like gcc and add
.def _nettle_arcfour_crypt; .scl 2; .type 32; .endef
in the assembly file. 32 is DT_FCN (see http://www.delorie.com/djgpp/doc/coff/symtab.html). Without this, I get T_NULL instead, and that somehow works with thatic linking but not wth dynamic linking. Now I only have to get configure to set this up correctly.
Some questions remain. Why didn't the other tests of functions with assembly implementation, in particular md5-test and sha1-test, fail in the same way?
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
Some questions remain. Why didn't the other tests of functions with assembly implementation, in particular md5-test and sha1-test, fail in the same way?
Hmm. That's most likely because the involved assembly function, _nettle_md5_compress, is called from within the dll, and not directly from md5-test.exe.
Regards, /Niels
Date: Fri, 30 May 2014 18:47:37 +0300 From: Eli Zaretskii eliz@gnu.org Cc: nettle-bugs@lists.lysator.liu.se
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 can confirm that the shared-library version crashes on Windows. More accurately, Windows refuses to run the test program, it pops up an error dialog saying "The application failed to initialize properly (0xc0000005). Click on OK to terminate the application." From what I gather by googling, this is indeed a sign of some kind of snafu with DLLs. I did verify that the arcfour-test.exe executable is linked against the correct libnettle-5.dll (I have a prior version installed on PATH).
If I configure with --disable-shared, the test program runs successfully.
Let me know if I can help you further.
Eli Zaretskii eliz@gnu.org writes:
I can confirm that the shared-library version crashes on Windows.
Thanks for testing. Just so I know, was that a native build or did you cross compile?
Let me know if I can help you further.
Hopefully, there should be a new version later today.
Regards, /Niels
From: nisse@lysator.liu.se (Niels Möller) Cc: nettle-bugs@lists.lysator.liu.se Date: Sat, 31 May 2014 09:58:18 +0200
Eli Zaretskii eliz@gnu.org writes:
I can confirm that the shared-library version crashes on Windows.
Thanks for testing. Just so I know, was that a native build or did you cross compile?
Native. Except that I didn't "make dist", but instead ran these commands directly in the git repo on Windows, after cloning it ("d:/usr" is where I keep my root of a Posix-like directory tree):
$ ./.bootstrap $ ./configure --prefix=d:/usr $ make $ make -C testsuite arcfour-test.exe $ cd testsuite && make check TS_ALL=arcfour-test.exe
Let me know if I can help you further.
Hopefully, there should be a new version later today.
OK, I will try that when it's available.
Eli Zaretskii eliz@gnu.org writes:
From: nisse@lysator.liu.se (Niels Möller) Hopefully, there should be a new version later today.
OK, I will try that when it's available.
I just pushed a fix to the git repo. 32-bit windows builds, with shared libraries, now work for me, using the mingw cross compiler and wine for testing. (I'll check status of 64-bit wine in debian, last time I looked it didn't work out of the box).
It would be great if you could test it, both for 32-bit and 64-bit windows.
Regards, /Niels
From: nisse@lysator.liu.se (Niels Möller) Cc: nettle-bugs@lists.lysator.liu.se Date: Sat, 31 May 2014 13:54:55 +0200
Eli Zaretskii eliz@gnu.org writes:
From: nisse@lysator.liu.se (Niels Möller) Hopefully, there should be a new version later today.
OK, I will try that when it's available.
I just pushed a fix to the git repo. 32-bit windows builds, with shared libraries, now work for me, using the mingw cross compiler and wine for testing. (I'll check status of 64-bit wine in debian, last time I looked it didn't work out of the box).
It would be great if you could test it, both for 32-bit and 64-bit windows.
Sorry, it still crashes for me in the same way.
I will try with another (newer) GCC version tomorrow.
Is it possible that some other dependency is screwing this up? E.g., I see that libgmp is required -- which version of GMP is needed for this version of nettle? I have v5.0.2 here.
Eli Zaretskii eliz@gnu.org writes:
Sorry, it still crashes for me in the same way.
That's disappointing... Does the new configure test work right for you? You should get
define(<ELF_STYLE>, <no>)dnl define(<COFF_STYLE>, <yes>)dnl
in config.m4, and a prologue like
.globl _nettle_arcfour_crypt .def _nettle_arcfour_crypt .scl 2 .type 32 .endef _nettle_arcfour_crypt:
in the preprocessed assembler files, e.g, arcfour-crypt.s.
For me, objdump -t arcfour-crypt.o now says
[ 2](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 1) 0x00000000 _nettle_arcfour_crypt
where the value for "ty" is important.
Is it possible that some other dependency is screwing this up? E.g., I see that libgmp is required -- which version of GMP is needed for this version of nettle? I have v5.0.2 here.
I think 5.0.2 should work fine. If you want to exclude this potential source of error, you can reconfigure with --disable-public-key.
Regards, /Niels
From: nisse@lysator.liu.se (Niels Möller) Cc: nettle-bugs@lists.lysator.liu.se Date: Sat, 31 May 2014 21:01:55 +0200
Eli Zaretskii eliz@gnu.org writes:
Sorry, it still crashes for me in the same way.
That's disappointing... Does the new configure test work right for you? You should get
define(<ELF_STYLE>, <no>)dnl define(<COFF_STYLE>, <yes>)dnl
in config.m4
That's what I get, yes.
and a prologue like
.globl _nettle_arcfour_crypt .def _nettle_arcfour_crypt .scl 2 .type 32 .endef _nettle_arcfour_crypt:
in the preprocessed assembler files, e.g, arcfour-crypt.s.
I don't have this file; how do I create it?
For me, objdump -t arcfour-crypt.o now says
[ 2](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 1) 0x00000000 _nettle_arcfour_crypt
where the value for "ty" is important.
I have this line in objdump's output, but it says
[ 24](sec 0)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x00000000 _nettle_arcfour_crypt
Are the differences between these two lines significant?
Is it possible that some other dependency is screwing this up? E.g., I see that libgmp is required -- which version of GMP is needed for this version of nettle? I have v5.0.2 here.
I think 5.0.2 should work fine. If you want to exclude this potential source of error, you can reconfigure with --disable-public-key.
That fixed the problem, so it must have been unrelated to the one you needed to (and did) solve. Not sure why libgmp I have caused trouble, I will look into that later.
Thanks.
Eli Zaretskii eliz@gnu.org writes:
From: nisse@lysator.liu.se (Niels Möller) You should get
define(<ELF_STYLE>, <no>)dnl define(<COFF_STYLE>, <yes>)dnl
in config.m4
That's what I get, yes.
Good.
in the preprocessed assembler files, e.g, arcfour-crypt.s.
I don't have this file; how do I create it?
It should be created in the build dir, as an intermediate step between .asm and .o. And appropriate .asm files are linked into the build dir by configure.
For me, objdump -t arcfour-crypt.o now says
[ 2](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 1) 0x00000000 _nettle_arcfour_crypt
where the value for "ty" is important.
I have this line in objdump's output, but it says
[ 24](sec 0)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x00000000 _nettle_arcfour_crypt
Are the differences between these two lines significant?
I guess not, but I don't know for sure.
Actually, "(sec 1)" in my build looks a bit suspicious, because according to objdump -x, section 1 is .data, and .text is section 0.
I think 5.0.2 should work fine. If you want to exclude this potential source of error, you can reconfigure with --disable-public-key.
That fixed the problem, so it must have been unrelated to the one you needed to (and did) solve. Not sure why libgmp I have caused trouble, I will look into that later.
In my windows cross-build, I don't have gmp available. I could try to cross build gmp too, to try to reproduce the problem, but probably not soon. If you wan't to track it down, it might be a good idea to first upgrade to gmp-6.
When you configure nettle with --disable-public-key, do both 32-bit and 64-bit windows builds work?
Regards, /Niels
From: nisse@lysator.liu.se (Niels Möller) Cc: nettle-bugs@lists.lysator.liu.se Date: Sat, 31 May 2014 21:48:15 +0200
In my windows cross-build, I don't have gmp available. I could try to cross build gmp too, to try to reproduce the problem, but probably not soon. If you wan't to track it down, it might be a good idea to first upgrade to gmp-6.
I will try.
When you configure nettle with --disable-public-key, do both 32-bit and 64-bit windows builds work?
Only 32-bit. I don't have a 64-bit development environment here.
Eli Zaretskii eliz@gnu.org writes:
From: nisse@lysator.liu.se (Niels Möller) When you configure nettle with --disable-public-key, do both 32-bit and 64-bit windows builds work?
Only 32-bit. I don't have a 64-bit development environment here.
Noted. Thanks for testing, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
(I'll check status of 64-bit wine in debian, last time I looked it didn't work out of the box).
Seems to work now, after
apt-get -t testing install wine wine32 wine64
Only problem is that it seems one can't use the same ~/.wine for 32-bit and 64-bit wine, so I have to set WINEPREFIX=~/.wine64 when running 64-bit executables.
It fails make check; several assembly functions crash on w64, also in the --disable-shared case. I haven't yet looked closer, but I suspect that's some simple bug in the register shuffling done to support the w64 calling convention. If it used to work (iirc, Martin tested the previous nettle release on w64), that probably means that it's correct for up to 5 arguments, but broken for newer functions with 6 arguments.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
It fails make check; several assembly functions crash on w64, also in the --disable-shared case. I haven't yet looked closer, but I suspect that's some simple bug in the register shuffling done to support the w64 calling convention.
Fixed now. Passes make check for me (in my mingw + wine cross environment), for both shared and static libraries. It would be nice if someone with a real 64-bit windows box could confirm that it works.
I've updated the release status at http://www.lysator.liu.se/~nisse/nettle/plan.html, and it's getting closer. It would be nice if someone could give it a try also on macos (as well as on any other systems that I don't test on myself).
Regards, /Niels
On Sun, 1 Jun 2014, Niels Möller wrote:
nisse@lysator.liu.se (Niels Möller) writes:
It fails make check; several assembly functions crash on w64, also in the --disable-shared case. I haven't yet looked closer, but I suspect that's some simple bug in the register shuffling done to support the w64 calling convention.
Fixed now. Passes make check for me (in my mingw + wine cross environment), for both shared and static libraries. It would be nice if someone with a real 64-bit windows box could confirm that it works.
I've updated the release status at http://www.lysator.liu.se/~nisse/nettle/plan.html, and it's getting closer. It would be nice if someone could give it a try also on macos (as well as on any other systems that I don't test on myself).
I've tested the latest git version on real windows (both 32 and 64 bit), OS X (both 32 and 64 bit), and on linux on arm (both armv6 and armv7 devices), and didn't run into any issues.
// Martin
On Mon, 2 Jun 2014, Martin Storsjö wrote:
On Sun, 1 Jun 2014, Niels Möller wrote:
nisse@lysator.liu.se (Niels Möller) writes:
It fails make check; several assembly functions crash on w64, also in the --disable-shared case. I haven't yet looked closer, but I suspect that's some simple bug in the register shuffling done to support the w64 calling convention.
Fixed now. Passes make check for me (in my mingw + wine cross environment), for both shared and static libraries. It would be nice if someone with a real 64-bit windows box could confirm that it works.
I've updated the release status at http://www.lysator.liu.se/~nisse/nettle/plan.html, and it's getting closer. It would be nice if someone could give it a try also on macos (as well as on any other systems that I don't test on myself).
I've tested the latest git version on real windows (both 32 and 64 bit), OS X (both 32 and 64 bit), and on linux on arm (both armv6 and armv7 devices), and didn't run into any issues.
To clarify - I ran "make check" and all tests passed, and these were shared builds (including GMP), not static.
// Martin
Martin Storsjö martin@martin.st writes:
I've tested the latest git version on real windows (both 32 and 64 bit), OS X (both 32 and 64 bit), and on linux on arm (both armv6 and armv7 devices), and didn't run into any issues.
Great! Thanks for testing, /Niels
nettle-bugs@lists.lysator.liu.se
-
Eli Zaretskii -
Martin Storsjö -
nisse＠lysator.liu.se