On 27 October 2014 15:11, Andy Polyakov <[email protected]> wrote: >>> I want to remind that question is *not* about removing run-time switch >>> as concept, but rather about distinguishing pre-ARMv7 and ARMv>=7. I.e. >>> NEON/cryto switch will stay, the only question if it's worth imposing it >>> on pre-ARMv7 builds [assuming that such binaries will be executed even >>> on ARMv>=7 systems]. >> >> Yes, that is perfectly clear. So we can target armv4 on the compiler >> command line, and still get crypto instructions when executing the >> resulting binary on a v8 system. >> >>>> So I would vote for #1, but with the .arch/.fpu declarations moved to >>>> the asm files. >>> This is undesired, because we don't want to make assumption that every >>> assembler actually supports these directives and required values. It's >>> safe to assume for big distro vendors, but there are people struggling >>> with exotic toolchains. >>> >> >> Well, in that case, will they be able to assemble the file in the >> first place, even with some -Wa, switch added? > > Yes, but developer would have the *freedom* to specify -Wa that matches > specific environment. > >> I know we deal with that using #ifdef's now, but those should be dropped imo. > > I'd like to drop them too, but I don't see it as question of liking, at > least not for now :-( > >> Perhaps we should introduce MIN_ARCH and MAX_ARCH variables, > > That's exactly what I meant by "convey the missing information by other > means, by additional -D option." It looks like specifying maximum would > be sufficient. I mean minimum would be controlled by -march to compiler > and then -Wa -DMAX could complement it. >
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. >> where the >> defaults are v4 and v8 respectively, and we can add Configure targets >> that narrow this down for targets like these? > > Right now there is only one linux-armv4, and there is no > architecture-specific flag there. This implies that you either rely on > compiler default or pass specific flag explicitly at configuration > stage. ./config actually does exactly this by adding -march=armv7-a if > executed on armv7 system. So as alternative to this you'd pass > -march=armvmin -Wa,-march=armvmax -D*MAX*=max, thus putting all controls > to users' hands. > >> ... #1 has my preference regardless. > > Got it. OK. So the existing linux-armv4 target becomes a 'native' target then, where the minimum architecture is decided by the compiler, and the maximum architecture is whatever the most advanced one is that supports all of the runtime selected options. Would it be sufficient to have a single alternative target where the max architecture == min architecture, both based on the compiler's default? ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
