On 27 October 2014 21:42, Andy Polyakov <[email protected]> wrote:
>> 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. 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.
In general, from .asm point of view, those #defines should only be
used to draw conclusions about how the /other/ code was built, e.g.,
for interworking.
> removing those #ifdefs would prevent user from specifying min==max==7
> and thumb. In other words logic around __thumb2__ might have to be
> refined, but I think it can still be useful.
Personally, I think there are few cases where Thumb2 makes sense, and
I would be perfectly happy for all the ARM .asm code to assemble to
ARM code only. What I do think is that we could refine the logic
around interworking returns based on those #defines instead of on the
ARCH, i.e., when lr is on the stack, we could do sth like
#if !defined(__thumb__) || defined(__thumb2__)
/* we are not being called by thumb-1 code */
ldmia sp!, {..., pc}
#else
/* do interworking return compatible with ARMv4T */
ldmia sp!, {..., lr}
bx lr
#endif
Note that this only works if the .asm function are only called
internally, but I think that is the case.
Anyway, I have been doing some tests, and it appears building for
ARMv5 does not work currently, due to the CNTVCT read in armv4cpuid.S.
Also, thumb-1 generates warning and I haven't figured out yet why.
--
Ard.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
