On 21/02/18 12:57 PM, Norm Green wrote:
On 2/21/2018 9:42 AM, Dennis Clarke wrote:
Which is correct way to do this on sparc systems.
Why do you say that? We've been building OpenSSL on SPARC for the past
7 years without that flag and it's worked just fine with only a few
minor changes to the compile/link flags.
The whole idea here is that openssl ( like a lot of things ) is supposed
to be portable code across a whack of platforms and while I can not
recall the dusty memories of why this option was invented way way back
in time I can at least quote the manual :
B.2.144 -xmemalign=ab
(SPARC) Use the -xmemalign option to control the assumptions that the
compiler makes about the alignment of data. By controlling the code
generated for potentially misaligned memory accesses and by controlling
program behavior in the event of a misaligned access, you can more
easily port your code to the SPARC platform.
Right ... like it says.
However what we are not saying here is what happens ( sig sig core dump
and halt ) when the system attempts to reach out and touch memory in an
icky way? You must provide a value for both alignment and behavior :
Alignment Behavior
1 at most 1 byte alignment. i Interpret access and continue exec
2 at most 2 byte alignment. s Raise signal SIGBUS
4 at most 4 byte alignment. f same as specifying i when the
alignment is 1, 2, or 4,
also same as s when a=8 or 16
8 at most 8 byte alignment.
16 at most 16 byte alignment.
So really we could do all manner of nasty things here and watch all
manner of performance results and cool coredumps and it would be fun to
try. However the option -xmemalign=8s will enforce "There should be no
misaligned accesses in the program".
So sayeth the manual going back way way back in time and so sayeth ye
gray beard here from experience. So I guess that is why I would say
this is the right way to do stuff.
Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
