>> 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.
Relevant question in the context is if all systems are that competent. And which approach would be adequately accepted. It probably makes more sense to harmonize with stock compiler than to make own assumptions. In other words which of the two suggested versions, defined(__thumb__) vs. defined(__ARM_ARCH_4T__) is least objectionable. > 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 In other words suggestion is to not bring moveq pc,lr back, but tell people what to do in specific situation. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
