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',
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]
