>>> Attached is promised patch that reworks >>> interworking logic. As mentioned earlier idea is to use __ARM_ARCH__>=5 >>> || !defined(__thumb__). Rationale is that load to pc does interworking >>> since ARMv5, but without __thumb__ it does what we need even on ARMv4. >>> >> >> OK, this appears to build and run fine when built for ARMv5/arm and >> ARMv5/thumb using the Ubuntu softfloat toolchains (arm-linux-gnueabi) >> >> The only use case that we may break is where someone links to the >> internal libcrypto.so symbols directly, and calls them from thumb code >> on an ARMv4t but I guess if you deserve the pain in that case :-) > > Correct. Those who attempt to run Thumb binary linked directly to e.g. > AES_encrypt in "universal" non-Thumb libcrypto.so specifically on ARMv4t > processor will suffer.
Well, it probably should be noted that Thumb code with non-Thumb shared library on ARMv4 takes special compiler. At least stock gcc doesn't generate those magic epilogues with moveq pc,lr, but simply issues "target CPU does not support interworking" warning. And passing -march=armv4t simply generates bx lr in both cases, i.e. with and without -mthumb... So that proposed pre-processor logic is actually out of sync with stock compiler and it makes sense to harmonize... I'll ponder and post another version. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
