>> No, not -c, but all the way so that it generates executable. Question is >> what is alignment of these variables in *final* executable, not >> intermediate .o. I should have been more explicit, sorry. > > My bad. Well it does explain why I couldn't interpret the output! > > =-=-=-=-=-=-=-= > cc -arch i386 -sectalign __DATA __common 4 -isysroot > /Developer/SDKs/MacOSX10.4u.sdk -o alignments alignments.s
For reference, idea behind non-default -sectalign was to see how it affects output. Formally library developers such as ourselves shouldn't/can't make too many assumptions and/or assume the worst. In the context wonder what it takes if a variable has to be aligned in specific manner [even if application does something like -sectalign]. Well, formally speaking in the case of OPENSSL_ia32cap_P any alignment would do, and you can accuse me for asking to perform test irrelevant to specific context of the query:-) > 0000204c S _four > 0000205c S _one > 00002060 S _two Hm. This means that if one wants to have _four aligned at 16 bytes it shouldn't be common. > and for comparison: > =-=-=-=-=-=-=-= > cc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -o alignments > alignments.s > 00002060 S _four > 00002070 S _one > 00002078 S _two Hm. Note that it didn't pad 4 bytes after _one above, but did so here. Curious... Oh well, I'll remove the 3rd argument... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
