On 10 November 2014 17:12, Andy Polyakov <ap...@openssl.org> wrote: >>>> 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. >
It probably emits R_ARM_V4BX relocations pointing to the locations of the 'bx lr' instructions, so that the linker can fix it up if you link for a non-thumb v4 target. Anyway, I agree it is not a use case we should care deeply about, as long as it is in the documentation somewhere that you shouldn't call OpenSSL internal functions directly from thumb code on a v4t -- Ard. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
