[openssl-dev] Making assembly language optimizations working onCortex-M3

[Brian Smith]

Peter Waltenberg <pwalten at au1.ibm.com> wrote:

> IF you are in the situation where you are compiling for a space
> constrained embedded processor then hopefully your engineers also have
> enough smarts to fix the code. I'd also point out that a lot of dev. setups
> for embedded aren't actually compiled on the target machine either so
> auto-detection at build time isn't that sensible anyway.
>
The BoringSSL works as follows:

1. The person building the code passes -DOPENSSL_STATIC_ARMCAP and some
other flags like -DOPENSSL_STATIC_ARMCAP_NEON, to indicate which features
are available on the target.

2. When OPENSSL_STATIC_ARMCAP is defined, the runtime detection of features
is disabled.

3. When OPENSSL_STATIC_ARMCAP is defined, OPENSSL_armcap_P is fixed to a
value based on which of DOPENSSL_STATIC_ARMCAP_NEON, etc. are defined.

4. When OPENSSL_STATIC_ARMCAP isn't defined, then everything works like it
currently does; i.e. features are detected at runtime.

The idea is that, instead having to go in and manually edit the code for
each different target system, one can just define these flags and the code
will auto-configure itself at build-time.

> The problem here is you can't have both and having the capability switch
> at runtime depending on hardware quirks is the better option for the
> majority of users.
>
That's usually true, but the topic of this thread is about how to get
OpenSSL working well on Cortex-M microcontrollers. In those situations, we
cannot really afford the dynamic detection or the many different
implementations of the same algorithm to exist in the final image.

Cheers,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160607/e4d6df52/attachment-0001.html>