Re: [PATCH] NetWare platform
Hi Andy, No, this particular instruction is not a problem, as it's essentially different ways to encode same thing (for reference, gnu assembler also uses shorter encoding). But it's right track, because it appears that metrowerks gets into trouble when the value exceeds 127. It fails to recognize that in this case compact encoding means sign extension. Most notably elsewhere nasm generates 8B94248000, mov edx,[esp+0x80], while metrowerks generates 8B542480, which disassembles as mov edx,[esp-0xff80]. edx is then dereferenced and written to, which causes unpredicted behavior, such as crash some place else. bingo! You nailed down the issue here! Its exactly that place. Since I'm clueless what you meant with 'removing padding in rmd-586.pl', for a test I did just replace the 'mov edx,[128+esp]' with the byte sequence NASM generated (at 2 places in the asm file), and with that the test suite successfully completed. Even though it's possible to work around this particular problem (by removing padding in rmd-586.pl), it's probably more appropriate to simply scrap metrowerks assembler support. Because one can't know when the bug strikes again and it's nothing but absurd to wait for this to happen. A. well, I can fully understand your point of view; but since the support for the Metrowerks assembler is anyway already in the sources for years, I would really like to keep that. It's anyway always recommened to run the test suite, and it seems that this reveals problems with the asm code, if any. Can you perhaps propose a patch which I could try? Then I would also like to do some performance measurements; how can I do that? I would like to compare the GNU / NASM / Metrowerks builds. thanks, Guenter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
No, this particular instruction is not a problem, as it's essentially different ways to encode same thing (for reference, gnu assembler also uses shorter encoding). But it's right track, because it appears that metrowerks gets into trouble when the value exceeds 127. It fails to recognize that in this case compact encoding means sign extension. Most notably elsewhere nasm generates 8B94248000, mov edx,[esp+0x80], while metrowerks generates 8B542480, which disassembles as mov edx,[esp-0xff80]. edx is then dereferenced and written to, which causes unpredicted behavior, such as crash some place else. bingo! You nailed down the issue here! Its exactly that place. Since I'm clueless what you meant with 'removing padding in rmd-586.pl', Look for Special comment in rmd-586.pl, 6 is expendable padding. for a test I did just replace the 'mov edx,[128+esp]' with the byte sequence NASM generated (at 2 places in the asm file), and with that the test suite successfully completed. This only means that netware test suite is far from complete. [esp+0x80] is address of 1st argument and references to other arguments are screwed up just as much. It worked by pure incident in the particular context, but it shall fail on longer inputs and/or depending on which functions were invoked earlier, or when asynchronous signal is delivered, etc. In other words replacing two above mentioned instructions with correct byte codes is far far away from sufficient. Even though it's possible to work around this particular problem (by removing padding in rmd-586.pl), it's probably more appropriate to simply scrap metrowerks assembler support. Because one can't know when the bug strikes again and it's nothing but absurd to wait for this to happen. well, I can fully understand your point of view; but since the support for the Metrowerks assembler is anyway already in the sources for years, I would really like to keep that. Why? It apparently didn't work for all those years anyway. Is it so hard to accept? It's anyway always recommened to run the test suite, and it seems that this reveals problems with the asm code, if any. See above, test suite passed, but the problem is still there, try rmdtest... or openssl rmd160 somefile... Can you perhaps propose a patch which I could try? Once again, it's *absurd* to work around this problem. Then I would also like to do some performance measurements; how can I do that? I would like to compare the GNU / NASM / Metrowerks builds. openssl speed. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
Output seems to be 16-bit .. Please regenerate disassembler listings. done; and I believe the issue shows already up in the first lines at 0014: Metrowerks: http://www.gknw.net/test/openssl/0.9.8-stable/mwasm/rm-nw.dis NASM: http://www.gknw.net/test/openssl/0.9.8-stable/nasm/rm-nw.dis the asm code is: sub esp,108 NASM produces for that: 0014 81EC6C00 sub esp,0x6c while Metrowerks code is: 0014 83EC6Csub esp,byte +0x6c No, this particular instruction is not a problem, as it's essentially different ways to encode same thing (for reference, gnu assembler also uses shorter encoding). But it's right track, because it appears that metrowerks gets into trouble when the value exceeds 127. It fails to recognize that in this case compact encoding means sign extension. Most notably elsewhere nasm generates 8B94248000, mov edx,[esp+0x80], while metrowerks generates 8B542480, which disassembles as mov edx,[esp-0xff80]. edx is then dereferenced and written to, which causes unpredicted behavior, such as crash some place else. I've 3 different versions of the Metrowerks Assembler, and all produce same wrong code here... no idea yet how to tell the stupid assembler to deal properly with that... Even though it's possible to work around this particular problem (by removing padding in rmd-586.pl), it's probably more appropriate to simply scrap metrowerks assembler support. Because one can't know when the bug strikes again and it's nothing but absurd to wait for this to happen. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
On related note question is what prevents you from always using nasm? Or rather do we actually need to support for metrowerks assembler? Basically if there is one working configuration for netware, what do we need second one for? well, that wasnt my idea, but it was 'historically'. I guess The Novell folks who did the initial OpenSSL port just started with the Metrowerks Assembler since its part of the Compiler package, and developers got this package delivered; probably also for debugging reasons since Metrowerks CodeWarrior comes with an IDE with source-level debugger; though at the moment I dont have that IDE installed, but use commandline tools only which is far more flexible reagrding path settings etc. Is it possible to link object modules compiled with nasm with object modules compiled with codewarrior? It might appear as silly question, but I know nothing about netware, while it sounds like some of netware development environments are cross-compile... Bottom line. I'd rather consider omitting metrowerks assembler support. probably if there's no way to work around the issue; but currently it seems that only 2 out of the 13 asm files are affected It's not about amount, but rather about not willing to support something that is commonly tested. With nasm one can at least assume that it has same qualities on all platforms, and it's commonly tested on some other platform. BTW. can you tell me for what the CPUID asm code is good for? Well, I can imagine what it does, but I'm curious for what its used The module as whole is a placeholder for short subroutines which are impossible to implement in C and hard to classify. As of now only couple of functions are used, most notably one returning CPU capability bit vector. Its return value is saved upon program start-up and is used to choose for example SSE2 code path only on SSE2-capable CPU, etc. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
It's not about amount, but rather about not willing to support something that is commonly tested. I naturally meant not willing to support something that is *not* commonly tested. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
Hi Andy, Is it possible to link object modules compiled with nasm with object modules compiled with codewarrior? It might appear as silly question, but I know nothing about netware, while it sounds like some of netware development environments are cross-compile... yes. There are a couple of different ways to compile for NetWare platform: - Metrowerks CodeWarrior C (official compiler, commercial) runing on Win32; produces COFF object code, and can be linked with NASM COFF object code. - gcc cross-compiler running on either Win32 or Linux; produces ELF object code, and can be linked with NASM ELF object code. - native Linux gcc + nlmconv (binutils); that's basically same as with cross-compiler, but lack of C++. It's not about amount, but rather about not willing to support something that is commonly tested. With nasm one can at least assume that it has same qualities on all platforms, and it's commonly tested on some other platform. yes, I understand. thanks for your reply! Guenter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
Is it possible to link object modules compiled with nasm with object modules compiled with codewarrior? It might appear as silly question, but I know nothing about netware, while it sounds like some of netware development environments are cross-compile... yes. There are a couple of different ways to compile for NetWare platform: - Metrowerks CodeWarrior C (official compiler, commercial) runing on Win32; produces COFF object code, and can be linked with NASM COFF object code. How come you were having trouble with .text segment alignment then? I mean if it's vanilla NASM COFF, then you shouldn't have had problem... How old is your nasm version? Could you check this and maybe test more up-to-date version? Or is it non-vanilla COFF? - gcc cross-compiler running on either Win32 or Linux; produces ELF object code, and can be linked with NASM ELF object code. ELF even on Win32? Then on Win32, do you compile under cygwin or mingw? Or in other words is there working GNU make? The point is that HEAD branch has certain support for cross-compilation, effectively meaning that Unix-like build procedure can be applied (as opposite to generating flat make-file and running some strange scripts), which is chosen to be preferred. This in turn means that I'd appreciate if you could explore this possibility. Basically read INSTALL.W32, look for cross-compile and see if HEAD can be adapted for this even for netware. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
Hi Andy, How come you were having trouble with .text segment alignment then? I I dont know... mean if it's vanilla NASM COFF, then you shouldn't have had problem... How old is your nasm version? Could you check this and maybe test more up-to-date version? Or is it non-vanilla COFF? plain vanilla COFF and latest nasm versions; check self: D:\openssl-SNAP-20071203\crypto\aes\asmaes-586.pl nw-nasm a-nw.asm D:\openssl-SNAP-20071203\crypto\aes\asmnasmw -v NASM version 0.99.06 compiled on Nov 1 2007 D:\openssl-SNAP-20071203\crypto\aes\asmnasmw -s -f coff a-nw.asm -o a-nw.o a-nw.asm:4: error: standard COFF does not support section alignment specificatio n D:\openssl-SNAP-20071203\crypto\aes\asme:\nasm-2.00rc1\nasm -v NASM version 2.00rc1 compiled on Nov 16 2007 D:\openssl-SNAP-20071203\crypto\aes\asme:\nasm-2.00rc1\nasm -s -f coff a-nw.asm -o a-nw.o a-nw.asm:4: error: standard COFF does not support section alignment specificatio n ELF even on Win32? Then on Win32, do you compile under cygwin or mingw? Or in other words is there working GNU make? The point is that HEAD plain Win32 OS with gnu make, no further autoconf tools required. branch has certain support for cross-compilation, effectively meaning that Unix-like build procedure can be applied (as opposite to generating flat make-file and running some strange scripts), which is chosen to be preferred. This in turn means that I'd appreciate if you could explore this possibility. Basically read INSTALL.W32, look for cross-compile and see if HEAD can be adapted for this even for netware. A. The Linux cross-builds are already non-mk1mf builds, and the libs are not an issue; but the executables like openssl.nlm are a bit a pain to get these properly created with configure-like builds; its better to control the exported symbols with export files - but if I use configure builds then just all symbols get exported as usual on Linux, and that's not what makes me happy since it might give naming clashes; so for now I would like to continue to use the working mk1mf builds on Win32. Also there's another problem were only with the 'official' Metrowerks compiler I can control struct alignments; gcc learned this only recently with 4.1.x version I think, but the available NetWare-cross gcc is still version 3.2.3 Another issue is that unless my patches go into HEAD I always have to patch around all few days to syncronize with the recent changes in HEAD; and that on two build platforms is a real pain... so once my other required patches are in HEAD I can certainly better look into any remaining issues or improvements such as trying a cross-build with MingW MSYS. here's my latest patch against recent snapshot: http://194.242.35.79/downloads/openssl/netware-openssl-SNAP-20071203.diff while trying to add the AES asm support I found that currently in HEAD the AES asm part is missing in mk1mf.pl - my patch does also add this part which I copied over from 0.9.8-stable where its included; however it seems that I'm missing something since it doesnt work: while I get the asm build rules in the netware makefile - somewhere else where the crypt library object files are build up there happens something strange = the asm object file is wrong; it gets prefixed with $(OBJ_D) and suffixed with '.o' which is wrong in this case; I've not yet found where this happens... thanks, Guenter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
Hi,
while trying to add the AES asm support I found that currently in HEAD the
AES asm part is missing in mk1mf.pl - my patch does also add this part
which I copied over from 0.9.8-stable where its included;
however it seems that I'm missing something since it doesnt work:
while I get the asm build rules in the netware makefile - somewhere else
where the crypt library object files are build up there happens something
strange = the asm object file is wrong;
it gets prefixed with $(OBJ_D) and suffixed with '.o' which is wrong in
this case;
I've not yet found where this happens...
ok, of course this happens in mk1mf.pl too with the regex I've copied over
from 0.9.8-stable - but I cant currently figure out why the regex fails;
without AES asm I get in the makefile:
$(OBJ_D)\aes_ctr.o $(OBJ_D)\aes_ige.o $(OBJ_D)\aes_core.o \
$(OBJ_D)\aes_cbc.o $(OBJ_D)\cmll_ecb.o $(OBJ_D)\cmll_ofb.o \
while with AES asm enabled I get:
$(OBJ_D)\aes_ctr.o $(OBJ_D)\aes_ige.o $(OBJ_D)\$(AES_ASM_OBJ).o \
$(OBJ_D)\cmll_ecb.o $(OBJ_D)\cmll_ofb.o $(OBJ_D)\cmll_cfb.o \
wich explains the prob; however I cant see why the replacement regex
in mk1mf.pl fails in this case; this is what I copied over:
if (($aes_asm_obj ne ) ($_ eq CRYPTO))
{
$lib_obj =~ s/\s(\S*\/aes_core\S*)/ \$(AES_ASM_OBJ)/;
$lib_obj =~ s/\s\S*\/aes_cbc\S*//;
$rules.=do_asm_rule($aes_asm_obj,$aes_asm_src);
}
all the other regex substitutes work fine
Guenter.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
I've still another problem with CodeWarrior Assembler in the ripemd asm code; with the tests it crashes while executing the command: openssl2 verify -CAfile \openssl\test_out\cert.tmp /openssl/certs/RegTP-5R.pem Could you define crashes? Does application exit with an error code or does application abnormally terminate so that OS offers to or does create a core dump (or whatever it's called in NetWare)? When I compile with nasm all works fine Does it mean that the C code in these two cases is compiled with same compiler and same compiler flags? In other words can you confirm that replacing single object file, one compiled with nasm with one compiled with metrowerks, triggers the fault? here are the asm files which get generated from the perlasm stuff: asm code for NASM (working): http://www.gknw.net/test/openssl/0.9.8-stable/nasm/rm-nw.asm object code disassembled with ndisasm: Output seems to be 16-bit and cover whole file (as opposite to disassembling executable segment only). In other words it's pretty worthless. Could you see you ndisasm manual and look for 32-bit flag and disassemble code only. Former is absolutely crucial to use, presuming that it will synchronize at same instruction early enough. Please regenerate disassembler listings. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
I've still another problem with CodeWarrior Assembler in the ripemd asm code; with the tests it crashes while executing the command: openssl2 verify -CAfile \openssl\test_out\cert.tmp /openssl/certs/RegTP-5R.pem Could you define crashes? Does application exit with an error code or does application abnormally terminate so that OS offers to or does create a core dump (or whatever it's called in NetWare)? I assume ABEND.LOG is answer to this question... When I compile with nasm all works fine Does it mean that the C code in these two cases is compiled with same compiler and same compiler flags? In other words can you confirm that replacing single object file, one compiled with nasm with one compiled with metrowerks, triggers the fault? But you still have to confirm that the fault is actually triggered by metrowerks assembler module. Trouble is that given the crash dump one would rather suspect compiler bug than module in question. On related note question is what prevents you from always using nasm? Or rather do we actually need to support for metrowerks assembler? Basically if there is one working configuration for netware, what do we need second one for? Furthermore. Most recent assembler modules detect CPU capabilities and pick most optimal code path. It's appropriate to enable support for this too. And given above question wouldn't it be easier to tinker with single target;-) Bottom line. I'd rather consider omitting metrowerks assembler support. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
Hi Andy, Could you define crashes? Does application exit with an error code or does application abnormally terminate so that OS offers to or does create a core dump (or whatever it's called in NetWare)? core dump. Does it mean that the C code in these two cases is compiled with same compiler and same compiler flags? In other words can you confirm that replacing single object file, one compiled with nasm with one compiled with metrowerks, triggers the fault? yes. Output seems to be 16-bit and cover whole file (as opposite to disassembling executable segment only). In other words it's pretty worthless. Could you see you ndisasm manual and look for 32-bit flag and disassemble code only. Former is absolutely crucial to use, presuming that it will synchronize at same instruction early enough. Please regenerate disassembler listings. A. done; and I believe the issue shows already up in the first lines at 0014: Metrowerks: http://www.gknw.net/test/openssl/0.9.8-stable/mwasm/rm-nw.dis NASM: http://www.gknw.net/test/openssl/0.9.8-stable/nasm/rm-nw.dis the asm code is: sub esp,108 NASM produces for that: 0014 81EC6C00 sub esp,0x6c while Metrowerks code is: 0014 83EC6Csub esp,byte +0x6c I've 3 different versions of the Metrowerks Assembler, and all produce same wrong code here... no idea yet how to tell the stupid assembler to deal properly with that... any hints what I should test welcome! thanks, Guenter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
Hi Andy, I assume ABEND.LOG is answer to this question... yup. But you still have to confirm that the fault is actually triggered by metrowerks assembler module. see my other post I just sent. On related note question is what prevents you from always using nasm? Or rather do we actually need to support for metrowerks assembler? Basically if there is one working configuration for netware, what do we need second one for? well, that wasnt my idea, but it was 'historically'. I guess The Novell folks who did the initial OpenSSL port just started with the Metrowerks Assembler since its part of the Compiler package, and developers got this package delivered; probably also for debugging reasons since Metrowerks CodeWarrior comes with an IDE with source-level debugger; though at the moment I dont have that IDE installed, but use commandline tools only which is far more flexible reagrding path settings etc. Bottom line. I'd rather consider omitting metrowerks assembler support. A. probably if there's no way to work around the issue; but currently it seems that only 2 out of the 13 asm files are affected - that are ripemd and aes (the rc4 fix I recently posted seems to work - and the aes code wasnt used at all up to now). BTW. can you tell me for what the CPUID asm code is good for? Well, I can imagine what it does, but I'm curious for what its used thanks for your replies! Guenter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
Hi all, but when using the CodeWarrior assembler then there's still one file broken: mwasmnlm -maxerrors 20 -o crypto/rc4/asm/r4-nw.o crypto/rc4/asm/r4-nw.asm ### mwasmnlm Assembler: #File: crypto\rc4\asm\r4-nw.asm # - # 112: lea esi,BYTE PTR [1+esi] # Error: # Invalid operand size ### mwasmnlm Driver Error: # The tool did not produce any output while compiling the file # 'crypto\rc4\asm\r4-nw.asm' Errors caused tool to abort. ok, I think I found the place were to fix this: --- rc4-586.pl.orig Thu Apr 26 22:00:56 2007 +++ rc4-586.plMon Nov 26 21:56:37 2007 @@ -143,7 +143,7 @@ movz ($ty,BP(0,$dat,$ty)); add(LB($xx),1); xor(LB($ty),BP(0,$inp)); - lea($inp,BP(1,$inp)); + lea($inp,DWP(1,$inp)); movz ($tx,BP(0,$dat,$xx)); cmp($inp,wparam(1)); mov(BP(-1,$out,$inp),LB($ty)); can someone with ASM insight please comment on the correctness of this patch? While the above patch seems to work -- at least all tests pass with that, I've still another problem with CodeWarrior Assembler in the ripemd asm code; with the tests it crashes while executing the command: openssl2 verify -CAfile \openssl\test_out\cert.tmp /openssl/certs/RegTP-5R.pem When I compile with nasm all works fine here are the asm files which get generated from the perlasm stuff: asm code for NASM (working): http://www.gknw.net/test/openssl/0.9.8-stable/nasm/rm-nw.asm object code disassembled with ndisasm: http://www.gknw.net/test/openssl/0.9.8-stable/nasm/rm-nw.dis asm code for Metrowerks Assembler (abending): http://www.gknw.net/test/openssl/0.9.8-stable/mwasm/rm-nw.asm object code disassembled with ndisasm: http://www.gknw.net/test/openssl/0.9.8-stable/mwasm/rm-nw.dis server abend log: http://www.gknw.net/test/openssl/0.9.8-stable/ABEND.LOG dump from binary: http://www.gknw.net/test/openssl/0.9.8-stable/openssl2.txt any hints greatly appreciated!! thanks, Guenter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
Hi Peter,
Comment out the align directive. All that's doing is making sure the code
is aligned with the machine cache boundaries for performance.
Unfortunately the COFF object format used on Netware doesn't support that
or at least that's what the assembler says.
It should still run fine without that, just maybe a bit slower.
thanks very much! That solved the COFF issue;
and I was now able to create a patch which solves this so far;
also I found while being on the asm stuff that the Metrowerks Assembler build
is also already broken for 0.9.8; this patch below tries to fix both the
Metrowerks and NASM issue... - well, almost:
--- x86nasm.pl.orig Wed Jul 25 14:01:40 2007
+++ x86nasm.pl Mon Nov 26 18:59:45 2007
@@ -92,6 +92,8 @@
{ my $tmp=___;
%ifdef __omf__
sectioncodeuse32 class=code align=64
+%elifdef __coff__
+section.text code
%else
section.text code align=64
%endif
@@ -102,9 +104,11 @@
sub ::function_begin_B
{ my $func=$under.shift;
+ my $global=(($::mwerks)?.:).global;
+ my $align=(($::mwerks)?.:).align;
my $tmp=___;
-global $func
-align 16
+$global$func
+$align 16
$func:
___
push(@out,$tmp);
@@ -213,7 +217,7 @@
sub ::public_label
{ $label{$_[0]}=${under}${_[0]} if (!defined($label{$_[0]}));
-push(@out,global\t$label{$_[0]}\n);
+push(@out,(($::mwerks)?.:).global\t$label{$_[0]}\n);
}
sub ::label
@@ -235,7 +239,7 @@
{ push(@out,(($::mwerks)?.long\t:dd\t).join(',',@_).\n); }
sub ::align
-{ push(@out,.) if ($::mwerks); push(@out,align\t$_[0]\n);}
+{ push(@out,(($::mwerks)?.:).align\t$_[0]\n); }
sub ::picmeup
{ my($dst,$sym)[EMAIL PROTECTED];
with that I'm now able to produce NASM ELF obj for gcc and COFF obj for
CodeWarrior compiler;
but when using the CodeWarrior assembler then there's still one file broken:
mwasmnlm -maxerrors 20 -o crypto/rc4/asm/r4-nw.o crypto/rc4/asm/r4-nw.asm
### mwasmnlm Assembler:
#File: crypto\rc4\asm\r4-nw.asm
# -
# 112: lea esi,BYTE PTR [1+esi]
# Error:
# Invalid operand size
### mwasmnlm Driver Error:
# The tool did not produce any output while compiling the file
# 'crypto\rc4\asm\r4-nw.asm'
Errors caused tool to abort.
when I replace the BYTE with DWORD it works, but the crazy thing is that in the
same file there's few lines up exactly the same line with DWORD:
@L002loop1:
add bl,cl
mov edx,DWORD PTR [ebx*4+edi]
mov DWORD PTR [ebx*4+edi],ecx
mov DWORD PTR [eax*4+edi],edx
add edx,ecx
inc al
and edx,255
mov edx,DWORD PTR [edx*4+edi]
xor dl,BYTE PTR [esi]
lea esi,DWORD PTR [1+esi] ; here's correct usage of DWORD
mov ecx,DWORD PTR [eax*4+edi]
cmp esi,DWORD PTR [24+esp]
mov BYTE PTR [esi*1+ebp-1],dl
jb @L002loop1
jmp @L004done
.align 16
@L001RC4_CHAR:
movzx ecx,BYTE PTR [eax*1+edi]
@L005cloop1:
add bl,cl
movzx edx,BYTE PTR [ebx*1+edi]
mov BYTE PTR [ebx*1+edi],cl
mov BYTE PTR [eax*1+edi],dl
add dl,cl
movzx edx,BYTE PTR [edx*1+edi]
add al,1
xor dl,BYTE PTR [esi]
lea esi,BYTE PTR [1+esi]; here's the line 112 which
uses BYTE with lea
movzx ecx,BYTE PTR [eax*1+edi]
cmp esi,DWORD PTR [24+esp]
mov BYTE PTR [esi*1+ebp-1],dl
jb @L005cloop1
I think that this is also a problem within x86nasm.pl,
however not yet found where to fix -- somebody who has a hint for me?
please let me know if the above patch is acceptable so far.
thanks, Guenter.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
Hi all, but when using the CodeWarrior assembler then there's still one file broken: mwasmnlm -maxerrors 20 -o crypto/rc4/asm/r4-nw.o crypto/rc4/asm/r4-nw.asm ### mwasmnlm Assembler: #File: crypto\rc4\asm\r4-nw.asm # - # 112: lea esi,BYTE PTR [1+esi] # Error: # Invalid operand size ### mwasmnlm Driver Error: # The tool did not produce any output while compiling the file # 'crypto\rc4\asm\r4-nw.asm' Errors caused tool to abort. ok, I think I found the place were to fix this: --- rc4-586.pl.orig Thu Apr 26 22:00:56 2007 +++ rc4-586.pl Mon Nov 26 21:56:37 2007 @@ -143,7 +143,7 @@ movz ($ty,BP(0,$dat,$ty)); add(LB($xx),1); xor(LB($ty),BP(0,$inp)); - lea($inp,BP(1,$inp)); + lea($inp,DWP(1,$inp)); movz ($tx,BP(0,$dat,$xx)); cmp($inp,wparam(1)); mov(BP(-1,$out,$inp),LB($ty)); can someone with ASM insight please comment on the correctness of this patch? thanks, Guenter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform - next trial
Hi,
Comment out the align directive. All that's doing is making sure the code
is aligned with the machine cache boundaries for performance.
Unfortunately the COFF object format used on Netware doesn't support that
or at least that's what the assembler says.
It should still run fine without that, just maybe a bit slower.
ok, just tested with SNAP-20071126, and few of my old issues are already fixed
now;
so here's what remains:
--- openssl-SNAP-20071126.orig/crypto/perlasm/x86nasm.pl2007-11-24
18:00:16.0 +0100
+++ openssl-SNAP-20071126/crypto/perlasm/x86nasm.pl 2007-11-26
23:09:17.0 +0100
@@ -94,6 +94,8 @@
{ my $tmp=___;
%ifdef __omf__
sectioncodeuse32 class=code align=64
+%elifdef __coff__
+section.text code
%else
section.text code align=64
%endif
diff -ur openssl-SNAP-20071126.orig/crypto/rc4/asm/rc4-586.pl
openssl-SNAP-20071126/crypto/rc4/asm/rc4-586.pl
--- openssl-SNAP-20071126.orig/crypto/rc4/asm/rc4-586.pl2007-04-26
23:00:56.0 +0200
+++ openssl-SNAP-20071126/crypto/rc4/asm/rc4-586.pl 2007-11-26
23:09:17.0 +0100
@@ -143,7 +143,7 @@
movz ($ty,BP(0,$dat,$ty));
add(LB($xx),1);
xor(LB($ty),BP(0,$inp));
- lea($inp,BP(1,$inp));
+ lea($inp,DWP(1,$inp));
movz ($tx,BP(0,$dat,$xx));
cmp($inp,wparam(1));
mov(BP(-1,$out,$inp),LB($ty));
but now I get a new issue:
mwasmnlm -maxerrors 20 -o crypto\des\asm\d-nw.o .\crypto\des\asm\d-nw.asm
### mwasmnlm Assembler:
#File: crypto\des\asm\d-nw.asm
#
#1147: call @L_DES_encrypt2_begin
# Error: ^
# Unknown identifier, @L_DES_encrypt2_begin
### mwasmnlm Assembler:
#1151: call @L_DES_encrypt2_begin
# Error: ^
# Unknown identifier, @L_DES_encrypt2_begin
### mwasmnlm Assembler:
#1155: call @L_DES_encrypt2_begin
# Error: ^
# Unknown identifier, @L_DES_encrypt2_begin
### mwasmnlm Assembler:
#1266: call @L_DES_encrypt2_begin
# Error: ^
# Unknown identifier, @L_DES_encrypt2_begin
### mwasmnlm Assembler:
#1270: call @L_DES_encrypt2_begin
# Error: ^
# Unknown identifier, @L_DES_encrypt2_begin
### mwasmnlm Assembler:
#1274: call @L_DES_encrypt2_begin
# Error: ^
# Unknown identifier, @L_DES_encrypt2_begin
### mwasmnlm Assembler:
#1366: call @L_DES_encrypt1_begin
# Error: ^
# Unknown identifier, @L_DES_encrypt1_begin
### mwasmnlm Assembler:
#1410: call @L_DES_encrypt1_begin
# Error: ^
# Unknown identifier, @L_DES_encrypt1_begin
### mwasmnlm Assembler:
#1426: call @L_DES_encrypt1_begin
# Error: ^
# Unknown identifier, @L_DES_encrypt1_begin
### mwasmnlm Assembler:
#1451: call @L_DES_encrypt1_begin
# Error: ^
# Unknown identifier, @L_DES_encrypt1_begin
### mwasmnlm Assembler:
#1548: call @L_DES_encrypt3_begin
# Error: ^
# Unknown identifier, @L_DES_encrypt3_begin
### mwasmnlm Assembler:
#1592: call @L_DES_encrypt3_begin
# Error: ^
# Unknown identifier, @L_DES_encrypt3_begin
### mwasmnlm Assembler:
#1608: call @L_DES_decrypt3_begin
# Error: ^
# Unknown identifier, @L_DES_decrypt3_begin
### mwasmnlm Assembler:
#1633: call @L_DES_decrypt3_begin
# Error: ^
# Unknown identifier, @L_DES_decrypt3_begin
### mwasmnlm Driver Error:
# The tool did not produce any output while compiling the file
# 'crypto\des\asm\d-nw.asm'
Errors caused tool to abort.
make: *** [crypto\des\asm\d-nw.o] Error 1
with SNAP-20071122 all files were previously compilable with my fix.
thanks, Guenter.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform - next trial
Hi, due to the changes from SNAP-20071122 to SNAP-20071126 I get now compiled: mwasmnlm -maxerrors 20 -o crypto/md5/asm/m5-nw.o crypto/md5/asm/m5-nw.asm mwasmnlm -maxerrors 20 -o crypto/sha/asm/s1-nw.o crypto/sha/asm/s1-nw.asm mwasmnlm -maxerrors 20 -o crypto/ripemd/asm/rm-nw.o crypto/ripemd/asm/rm-nw.asm mwasmnlm -maxerrors 20 -o crypto/des/asm/y-nw.o crypto/des/asm/y-nw.asm mwasmnlm -maxerrors 20 -o crypto/bn/asm/bn-nw.o crypto/bn/asm/bn-nw.asm mwasmnlm -maxerrors 20 -o crypto/rc4/asm/r4-nw.o crypto/rc4/asm/r4-nw.asm and here it starts breaking: mwasmnlm -maxerrors 20 -o crypto/bf/asm/b-nw.o crypto/bf/asm/b-nw.asm ### mwasmnlm Assembler: #File: crypto\bf\asm\b-nw.asm # --- # 740: call @L_BF_encrypt_begin # Error: ^^^ # Unknown identifier, @L_BF_encrypt_begin ### mwasmnlm Assembler: # 788: call @L_BF_encrypt_begin # Error: ^^^ # Unknown identifier, @L_BF_encrypt_begin ### mwasmnlm Assembler: # 808: call @L_BF_decrypt_begin # Error: ^^^ # Unknown identifier, @L_BF_decrypt_begin ### mwasmnlm Assembler: # 837: call @L_BF_decrypt_begin # Error: ^^^ # Unknown identifier, @L_BF_decrypt_begin ### mwasmnlm Driver Error: # The tool did not produce any output while compiling the file # 'crypto\bf\asm\b-nw.asm' Errors caused tool to abort. make: *** [crypto/bf/asm/b-nw.o] Error 1 mwasmnlm -maxerrors 20 -o crypto/cast/asm/c-nw.o crypto/cast/asm/c-nw.asm ### mwasmnlm Assembler: #File: crypto\cast\asm\c-nw.asm # - # 785: call @L_CAST_encrypt_begin # Error: ^ # Unknown identifier, @L_CAST_encrypt_begin ### mwasmnlm Assembler: # 835: call @L_CAST_encrypt_begin # Error: ^ # Unknown identifier, @L_CAST_encrypt_begin ### mwasmnlm Assembler: # 855: call @L_CAST_decrypt_begin # Error: ^ # Unknown identifier, @L_CAST_decrypt_begin ### mwasmnlm Assembler: # 884: call @L_CAST_decrypt_begin # Error: ^ # Unknown identifier, @L_CAST_decrypt_begin ### mwasmnlm Driver Error: # The tool did not produce any output while compiling the file # 'crypto\cast\asm\c-nw.asm' Errors caused tool to abort. make: *** [crypto/cast/asm/c-nw.o] Error 1 mwasmnlm -maxerrors 20 -o crypto\des\asm\d-nw.o .\crypto\des\asm\d-nw.asm ### mwasmnlm Assembler: #File: crypto\des\asm\d-nw.asm # #1147: call @L_DES_encrypt2_begin # Error: ^ # Unknown identifier, @L_DES_encrypt2_begin ### mwasmnlm Assembler: #1151: call @L_DES_encrypt2_begin # Error: ^ # Unknown identifier, @L_DES_encrypt2_begin ### mwasmnlm Assembler: #1155: call @L_DES_encrypt2_begin # Error: ^ # Unknown identifier, @L_DES_encrypt2_begin ### mwasmnlm Assembler: #1266: call @L_DES_encrypt2_begin # Error: ^ # Unknown identifier, @L_DES_encrypt2_begin ### mwasmnlm Assembler: #1270: call @L_DES_encrypt2_begin # Error: ^ # Unknown identifier, @L_DES_encrypt2_begin ### mwasmnlm Assembler: #1274: call @L_DES_encrypt2_begin # Error: ^ # Unknown identifier, @L_DES_encrypt2_begin ### mwasmnlm Assembler: #1366: call @L_DES_encrypt1_begin # Error: ^ # Unknown identifier, @L_DES_encrypt1_begin ### mwasmnlm Assembler: #1410: call @L_DES_encrypt1_begin # Error: ^ # Unknown identifier, @L_DES_encrypt1_begin ### mwasmnlm Assembler: #1426: call @L_DES_encrypt1_begin # Error: ^ # Unknown identifier, @L_DES_encrypt1_begin ### mwasmnlm Assembler: #1451: call @L_DES_encrypt1_begin # Error: ^ # Unknown identifier, @L_DES_encrypt1_begin ### mwasmnlm Assembler: #1548: call @L_DES_encrypt3_begin # Error: ^ # Unknown identifier, @L_DES_encrypt3_begin ### mwasmnlm Assembler: #1592: call @L_DES_encrypt3_begin # Error: ^ # Unknown identifier, @L_DES_encrypt3_begin ### mwasmnlm Assembler: #1608: call @L_DES_decrypt3_begin # Error: ^ # Unknown identifier, @L_DES_decrypt3_begin ### mwasmnlm Assembler: #1633: call @L_DES_decrypt3_begin # Error: ^ # Unknown identifier, @L_DES_decrypt3_begin ### mwasmnlm Driver Error: # The tool did not produce any output while compiling the file # 'crypto\des\asm\d-nw.asm' Errors caused tool to abort. make: *** [crypto\des\asm\d-nw.o] Error 1 mwasmnlm -maxerrors 20 -o crypto/rc5/asm/r5-nw.o crypto/rc5/asm/r5-nw.asm ### mwasmnlm Assembler: #File: crypto\rc5\asm\r5-nw.asm # - # 422: call
Re: [PATCH] NetWare platform
On Thu, Nov 22, 2007, Guenter Knauf wrote: Hi all, I develop since years for the NetWare platform. In the past I did just send my patches to the Novell developers who maintained the NetWare OpenSSL port, but they are no longer with Novell, and it seems that at Novell nobody cares now about the port. Therefore I subscribed here, and want to ask for inclusion of this patch: http://194.242.35.79/downloads/openssl/netware-openssl-0.9.8g.diff as you can already read in the header of the patch this solves a couple of issues which arised with what's currently in the OpenSSL source tree; also I've added more targets which I need for my projects which consume the OpenSSL library. Currently I have 3 major projects Apache2, PHP, cURL which I compile and distribute on regular basis, and I'm tired of patching always each new version of OpenSSL, so please add this patch before next release. Can you please send this to the request tracker so it doesn't get mislaid? See http://www.openssl.org/support/rt.html It would be great if you could include a patch for 0.9.9-dev too. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
Hi Steve, Can you please send this to the request tracker so it doesn't get mislaid? See http://www.openssl.org/support/rt.html did that about 2 hours ago, but it doesnt show up yet on the tracker overview. It would be great if you could include a patch for 0.9.9-dev too. Do I assume right that at ftp://ftp.openssl.org/snapshot/ those archives with naming openssl-SNAP-2007mmdd.tar.gz are the 0.9.9-dev? thanks, Guenter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
In message [EMAIL PROTECTED] on Thu, 22 Nov 2007 21:31:44 +0100, Guenter Knauf [EMAIL PROTECTED] said: eflash Hi Steve, eflash Can you please send this to the request tracker so it doesn't get mislaid? eflash eflash See http://www.openssl.org/support/rt.html eflash did that about 2 hours ago, but it doesnt show up yet on the tracker overview. The moderator needs to wake up ;-). eflash It would be great if you could include a patch for 0.9.9-dev too. eflash Do I assume right that at ftp://ftp.openssl.org/snapshot/ eflash those archives with naming openssl-SNAP-2007mmdd.tar.gz are the 0.9.9-dev? Yes. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare platform
Hi, eflash See http://www.openssl.org/support/rt.html eflash did that about 2 hours ago, but it doesnt show up yet on the tracker overview. The moderator needs to wake up ;-). Ahh yes - I assumed a machine behind, hehe... eflash It would be great if you could include a patch for 0.9.9-dev too. eflash Do I assume right that at ftp://ftp.openssl.org/snapshot/ eflash those archives with naming openssl-SNAP-2007mmdd.tar.gz are the 0.9.9-dev? Yes. ok, I made so far good progress with that, and could finally create a patch there too; but I've a problem with one ASM file; here's the error with nasm: nasmw -s -f coff -o crypto\md5\asm\m5-nw.o .\crypto\md5\asm\m5-nw.asm .\crypto\md5\asm\m5-nw.asm:4: error: standard COFF does not support section alignment specification make: *** [crypto\md5\asm\m5-nw.o] Error 1 and here's the error with same file when used Metrowerks CodeWarrior Assembler: mwasmnlm -maxerrors 20 -o crypto\md5\asm\m5-nw.o .\crypto\md5\asm\m5-nw.asm ### mwasmnlm Assembler: #File: crypto\md5\asm\m5-nw.asm # - # 2: global md5_block_asm_data_order # Error: ^^ # Undefined macro or opcode: global ### mwasmnlm Assembler: # 3: align 16 # Error: ^ # Undefined macro or opcode: align ### mwasmnlm Driver Error: # The tool did not produce any output while compiling the file 'crypto\md5\asm\m5-nw.asm' Errors caused tool to abort. make: *** [crypto\md5\asm\m5-nw.o] Error 1 however when I build with gcc then I use ELF format, and dont have this problem. since I'm not an ASM wizzard I would need some help with that issue... thanks in advance! Guenter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
