>>> OK, that sounds doable. But if -Wa is going to be used as a matter of >>> course to pass arch/fpu options, we should get rid of all #ifdef's >>> against things like __thumb2__, as they can be out of sync. >> First of all users would have to recognize and accept that they can't >> pass -march=armv4 to compiler and at the same time instruct assembler to >> generate thumb. Because it would undermine whole idea. Then keep in mind >> that -march=armv4 would never define __thumb2__, so that as long as we >> look at __ARM_ARCH__ (and not __ARM_MAX_ARCH__) when choosing between >> .thumb and .code 32, it's not a problem from preprocessor viewpoint. But > > My point was that, in general, #defines regarding to arch, > thumb/thumb2/arm and soft/hard float are based on the compiler > options, not the assembler options.
That's what I'm saying too. > One such issue is in aes-armv4.S, > where the .code 32/.thumb declaration is emittted based on an #ifdef. > However, I could have passed -Wa,-marm because I know my assembler is > incompatible with the thumb2 variant of the code. As already said, user would have to recognize that some combinations would be invalid. Specifically assembler options would always have to be "better" than compiler options, but not too much "better". If you asked compiler to generate thumb code, you may not revoke it from assembler. At the same time if you pass -march=armv4 to compiler, you may not ask assembler to generate thumb even if you specify -Wa,-march=armv7, not on command line that is. You can choose to switch to thumb with directive *in* assembly module, but it would have to happen in #if MAX>X section. Though I see no reason to do so in universal binary. Anyway. As nobody seems to be objecting, it sounds like we are going for combination of both alternatives? I.e. those who specify specific -march lower than armv7 would be excused from capability detection and run-time switch, and those who additionally specify "better" -Wa and corresponding -D, would be able to build universal binaries of their liking. I'll give it some extra time for others to ponder and make a suggestion. It would be easier to discuss details then. I'm taking into consideration your feedback about interworking. As for CNTVCT, it's known, fix is pending. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
