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
> 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. 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]
