Andy Polyakov <ap...@openssl.org> wrote: > > Cortex-M3 and Cortex-M4 processors are -mthumb, -march=armv7-m, which is > > exactly the problematic configuration, if I understand that comment > > correctly. > > The comment in question applies *exclusively* to cases when you attempt > to build "universal" binary, one that works on multiple platforms, e.g. > on ARMv6 and ARMv7. >
<snip> OK. Thanks for clarifying things. > Has anybody started working on this? > > > > If not, my thinking was to refactor the assembly language code so that > > all the ARM-only (-marm) code is cleanly separated from the unified > > (-mthumb and -marm) code, > > As implied, there are few assembly modules that *can* be compiled for > Thumb-2 today, namely aes-armv4, bsaes-armv7, sha256-armv4, > sha512-armv4. Is there evidence that we can't adhere to this strategy of > adjusting modules for ARM/Thumb-2 "duality"? That sounds good to me. > (BTW, can you confirm that you can get mentioned modules work?) > Yes, I am able to compile those modules: git clone https://github.com/briansmith/openssl arm-openssl cd arm-openssl ./configure-arm-none-eabi.sh make depend make In particular, see this commit to understand the configuration: https://github.com/briansmith/openssl/commit/ffa6e0c7a575184bc171b72a7ff3715bde460163 I am using the toolchain from [1]: arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288] I ran out of time this weekend before I could test out the resultant library though. > > and recognize two new settings, > > OPENSSL_NO_ARM_NEON and OPENSSL_ARM_THUMB_ONLY, to accommodate this. > > While NO_NEON might make sense, I really see no reason to introduce > THUMB_ONLY. Because pre-defines set by the compiler driver are > sufficient. You mean, using __thumb__ (predefined for both thumb1 and thumb2) and __thumb2__ (predefined for thumb2 only)? > Actually, one can argue that even decision to omit NEON code > can be made based on pre-defines, e.g. __ARM_ARCH_7M__. Well, this > doesn't exclude possibility to define NO_NEON based on pre-define and > using NO_NEON in code. Right. If you are building for Cortex-A (armv7-a) then you may or may not want the NEON detection, depending on how much you know about the users' hardware in advance. Consequently, I think having an OPENSSL_ARM_NO_NEON option is useful. > A word of warning. When looking at ARM assembly code, you might find > yourself asking "why isn't this done this way?" It's likely that answer > to that question is "because old assembler fails to compile it." I mean > there is certain level of legacy support there and it's not a coincidence. > Understood. I also looked at some of the past commits where thumb2 support was added, e.g. [2]. So, basically, we just need to (a) understand which modules are thumb2-only and which aren't, and (b) adjust more modules to work for thumb2. I am mostly interested in getting the AES-GCM and sha1 assembly language optimizations working for this configuration. You mentioned in your message that you already have ghash working for thumb2. Is that right? [1] https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded [2] https://github.com/openssl/openssl/commit/e0202d946d68bd91a3e99f223c66d1fce7db136a Thanks for your help! Cheers, Brian -- https://briansmith.org/
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev