<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Andy Polyakov <span dir="ltr"><<a href="mailto:appro@openssl.org" target="_blank">appro@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> Cortex-M3 and Cortex-M4 processors are -mthumb, -march=armv7-m, which is<br>
> exactly the problematic configuration, if I understand that comment<br>
> correctly.<br>
<br>
</span>The comment in question applies *exclusively* to cases when you attempt<br>
to build "universal" binary, one that works on multiple platforms, e.g.<br>
on ARMv6 and ARMv7.<br></blockquote><div><br></div><div><snip></div><div><br></div><div>OK. Thanks for clarifying things.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Has anybody started working on this?<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
><br>
> If not, my thinking was to refactor the assembly language code so that<br>
> all the ARM-only (-marm) code is cleanly separated from the unified<br>
> (-mthumb and -marm) code,<br>
<br>
</span>As implied, there are few assembly modules that *can* be compiled for<br>
Thumb-2 today, namely aes-armv4, bsaes-armv7, sha256-armv4,<br>
sha512-armv4.</blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is there evidence that we can't adhere to this strategy of<br>
adjusting modules for ARM/Thumb-2 "duality"?</blockquote><div><br></div><div>That sounds good to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(BTW, can you confirm that you can get mentioned modules work?)<br></blockquote><div><br></div><div>Yes, I am able to compile those modules:</div><div><br></div><div>git clone <a href="https://github.com/briansmith/openssl">https://github.com/briansmith/openssl</a> arm-openssl<br></div><div>cd arm-openssl</div><div>./configure-arm-none-eabi.sh</div><div>make depend</div><div>make</div><div><br></div><div>In particular, see this commit to understand the configuration: <a href="https://github.com/briansmith/openssl/commit/ffa6e0c7a575184bc171b72a7ff3715bde460163">https://github.com/briansmith/openssl/commit/ffa6e0c7a575184bc171b72a7ff3715bde460163</a></div><div><br></div><div> I am using the toolchain from [1]:</div><div><br></div><div><div>arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors)</div><div>4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]</div></div><div><br></div><div><br></div><div>I ran out of time this weekend before I could test out the resultant library though.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> and recognize two new settings,<br>
> OPENSSL_NO_ARM_NEON and OPENSSL_ARM_THUMB_ONLY, to accommodate this.<br>
<br>
</span>While NO_NEON might make sense, I really see no reason to introduce<br>
THUMB_ONLY. Because pre-defines set by the compiler driver are<br>
sufficient. </blockquote><div><br></div><div>You mean, using <span style="color:rgb(0,0,0)">__thumb__ (predefined for both thumb1 and thumb2) and </span><span style="color:rgb(0,0,0)">__thumb2__ (predefined for thumb2 only)?</span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Actually, one can argue that even decision to omit NEON code<br>
can be made based on pre-defines, e.g. __ARM_ARCH_7M__. Well, this<br>
doesn't exclude possibility to define NO_NEON based on pre-define and<br>
using NO_NEON in code.</blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A word of warning. When looking at ARM assembly code, you might find<br>
yourself asking "why isn't this done this way?" It's likely that answer<br>
to that question is "because old assembler fails to compile it." I mean<br>
there is certain level of legacy support there and it's not a coincidence.<br></blockquote><div><br></div><div>Understood.</div><div><br></div><div>I also looked at some of the past commits where thumb2 support was added, e.g. [2].</div><div><br></div><div>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?</div><div><br></div><div>[1] <a href="https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded">https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded</a><br></div><div>[2] <a href="https://github.com/openssl/openssl/commit/e0202d946d68bd91a3e99f223c66d1fce7db136a">https://github.com/openssl/openssl/commit/e0202d946d68bd91a3e99f223c66d1fce7db136a</a></div><div><br></div><div>Thanks for your help!</div><div><br></div><div>Cheers,</div><div>Brian</div><div>--</div><div><a href="https://briansmith.org/">https://briansmith.org/</a></div><div><br></div></div>
</div></div>