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]