From: Andy Polyakov <ap...@openssl.org> Date: Fri, 21 Sep 2012 12:21:25 +0200
> I'll handle this, but differently. Specifically I won't go through GOT, > but directly to variable, something like this: I would like to politely request that you don't go down this road. > .Lretl: > retl > nop > ... > sethi %hi(var-.Lpic),%reg > .Lpic: call .Lretl > add %o7,%lo(var-.Lpic),%reg I honestly think it's easiest to to simply generate correct PIC sequences, as my macros are trying to do. We can add whatever ifdefs and code generation cases we need to sparc_arch.h The code that I'm emitting is identical to what GCC generates on Linux and Solaris under Sparc regardless of which assembler and linker are in use. I should know, I wrote much of the sparc GCC backend. If you describe to me what problems your scheme ran into, I can fix them up. Did you test if my code sequences work for you? It is also important to note that they are also specifically designed to be usable in leaf functions. BTW, the real long term answer is mark openssl internal symbols as "hidden" and then use GOT_DATA optimization sequences which will get rid of the GOT reference altogether. But that requires some configure checks to see if the assembler and linker support these constructs. > As for OPENSSL_sparcv9cap_P itself. I'd rather extend it to int > OPENSSL_sparcv9cap_P[2] and save %cfr as is to OPENSSL_sparcv9cap_P[1]. > Any objections? I think this is code masterbation at this early stage of the sparc crypto opcode support implementation and is something we can clean up later. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
