On Thu July 17 2008 19:36, Ger Hobbelt wrote:
> > I believe it has worked in our code for years; however, the problem is
> > now to make it work on FreeBSC-sparc64. :(
> 
> 
> Hm, this may be a stupid remark (I seem to be good at those lately),
> but do you compile your own code with gcc too?
> 
> 
> I've ported OpenSSL to other hardware in the past; the first thing I
> did was to make sure that:
> 
> 1) the compiler used to build your own (working) code is the one
> compiling OpenSSL
> 
> 2) get rid of the -O optimization == compile at no optimizations at all
>

While changing the -O flag - - also add the -v flag
That will generate a lot of messy output but included in the
output will be the full path of each tool in the toolchain used.

If your machine has more than a single C compiler (or any other
tool) installed - this is how to learn if the build is using
the one you thought it would.

You might do that to the build of your "working" code also -
just for reference as to which tool was used.

Mike 
> 3) also get rid of any assembly provided by OpenSSL; to force it out,
> you can #define OPENSSL_NO_ASM
> 
> 4) check the word size for your compile (the platform may be
> 64/whatever-bit, but you may be building a 32/other-bit binary on it
> -- please note that i do NOT know OpenBSD on Sparc; regard this as a
> very generic list for when you don't know the target hardware yet.)
> 
> 5) build the OpenSSL test apps (including the 'MONOLITH' openssl app)
> and check if those binaries work.
> 
> 6) if you get weirdo results in (5), check if the compiler/hardware
> produces correct code for signed and unsigned right shift (which may
> be encoded as arithmetic or logical shift in assembly by the compiler
> - beware I'm not talking about /good/ compilers here!) and a few other
> bits 'n pieces. This is the hairpull stage. Seems you're already here
> anyway. Anything goes.
> 
> 
> NOTE: If (1) cannot apply to your situation, forget about this all.
> 
> Another thing you may already have thought of: when you wish to debug
> this sort of thing by comparing against another box - which provably
> works - do the 'Debian' thing, but now /knowingly/: disable entropy
> collection by hacking the OpenSSL code (you can throw it away later);
> feed both boxes (SSL-enabled binaries) the exact same predefined set
> of 'random' bytes and run the same session on both: this will allow
> you to compare the numbers for identity step by step as you killed all
> randomness and made it fully predictable. Where the behaviour/numbers
> between the two boxes start to differs, you're near the bug zone.
> Worst (and ultra-rare) case, you may have to disassemble the code and
> simulate it, but I hope you'll never get to go /that/ deep.
> 
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to