This is a discussion on Re: sha test failing on MkLinux PPC - Openssl ; >>>With the wide variety of platforms, it is not unusual for >>>problems to show up on only one platform. >> >>Yes, but when it does, it's more and more likely to mean that it's >>something wrong with end-developer environment, e.g. ...
>>>With the wide variety of platforms, it is not unusual for
>>>problems to show up on only one platform.
>>Yes, but when it does, it's more and more likely to mean that it's
>>something wrong with end-developer environment, e.g. a
>>Naturally provided that platform is correctly recognized by
> Config knows about VOS and selects "no-threads no-shared no-asm no-dso".
Oh! You're the VOS guy! I have some questions to you, which I'll post
off-list... If that's OK...
> #if defined(__i386) || defined(__i386__) || defined(_M_IX86) ||
> * *_block_host_order is expected to handle aligned data while
> * *_block_data_order - unaligned. As algorithm and host (x86)
> * are in this case of the same "endianness" these two are
> * otherwise indistinguishable.
> #define md4_block_data_order md4_block_host_order
> Maybe I don't understand this code as well as I thought, but the way I read
> this code, the algorithm is expecting data in LE order, and is presuming
> that Intel platforms also store data in LE order. That assumption is
> incorrect for our (admittedly rather unusual) platform. As coded, md4 fails
> on our BE Intel platform. When I recoded this #if statement to not be true,
> md4 worked. What am I missing?
Apparently nothing. I mean yes, you're right that in this place
endianness is indeed assumed based upon compiler macro. It's just that I
couldn't imagine, not even in a wildest dream, that someone would come
up with idea to *emulate* big-endiannes at compiler level. I would
actually even argue that in such case it's not appropriate for compiler
to preserve __i386 macro, it should have defined __i386be or
something... I mean I find it hard to believe that I would the only one,
who would get an idea to make assumption about __i386 being little-endian...
>>>As it happens, I have a
>>>big-endian environment on an Intel box,
>>Is it really possible? Is there an x86 big-endian? Is it possible to
>>switch Intel x86 to big-endian? What OS does it run? Which
>>config line does OpenSSL picks then?
> the compilers that we wrote or ported produce the necessary byte-swap
> instructions. All user-visible data in main memory is stored in big-endian
> format, and the compilers byte-swap when necessary.
Well, I wouldn't call it big-endian x86, as CPU still picks data in
little-endian order. It's really a "WOW!" that you actually do it, but I
wouldn't say "admittedly rather unusual," but "no doubt absolutely
unique." So unique that you really shouldn't have preseved __i386 macro
in your utterly special compiler, if you ask my opinion:-)
>>>Take a close look at some of the #if macro tests in, for example,
>>>crypto/sha/sha_locl.h. You could be hitting a similar problem.
>>I bet not:-) As mentioned, it smells a compiler bug...
> OK, you're on.
You assert that tweaking those #if statements would help MkLinux(!) and
I assert that it wouldn't.
> I'll take a Sam Adams, please, if I'm right.
What's "Sam Adams"?
> What's your pleasure?
I'm more realistic, so a postcard would suffice:-) A.
OpenSSL Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org