Output seems to be 16-bit .. Please
regenerate disassembler listings.
done; and I believe the issue shows already up in the first lines at 00000014:
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:
00000014 81EC6C000000 sub esp,0x6c
while Metrowerks code is:
00000014 83EC6C sub 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
8B942480000000, mov edx,[esp+0x80],
while metrowerks generates
8B542480, which disassembles as mov edx,[esp-0xffffff80].
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]
