From mboxrd@z Thu Jan 1 00:00:00 1970 From: tixy@yxit.co.uk (Tixy) Date: Wed, 01 Jun 2011 14:04:36 +0100 Subject: [PATCH REPOST] ARM: Thumb-2: Relax relocation requirements for non-function symbols In-Reply-To: <1306859269-21304-1-git-send-email-dave.martin@linaro.org> References: <1306859269-21304-1-git-send-email-dave.martin@linaro.org> Message-ID: <1306933476.26071.9.camel@computer2> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, 2011-05-31 at 17:27 +0100, Dave Martin wrote: > The "Thumb bit" of a symbol is only really meaningful for function > symbols (STT_FUNC). > > However, sometimes a branch is relocated against a non-function > symbol; for example, PC-relative branches to anonymous assembler > local symbols are typically fixed up against the start-of-section > symbol, which is not a function symbol. Some inline assembler > generates references of this type, such as fixup code generated by > macros in . > > The existing relocation code for R_ARM_THM_CALL/R_ARM_THM_JUMP24 > interprets this case as an error, because the target symbol appears > to be an ARM symbol; but this is really not the case, since the > target symbol is just a base in these cases. The addend defines > the precise offset to the target location, but since the addend is > encoded in a non-interworking Thumb branch instruction, there is no > explicit Thumb bit in the addend. Because these instructions never > interwork, the implied Thumb bit in the addend is 1, and the > destination is Thumb by definition. > > This patch removes the extraneous Thumb bit check for non-function > symbols, enabling modules containing the affected relocation types > to be loaded. No modification to the actual relocation code is > required, since this code does not take bit[0] of the > location->destination offset into account in any case. > > Function symbols are always checked for interworking conflicts, as > before. The checks in both Thumb and ARM relocation code to prevent interworking mean that BLX instructions can't be relocated. Does this mean that: a) We don't care about BLX instructions as they shouldn't normally be produced (except in my kprobe test cases ;-) b) We should remove the checks in the relocation code preventing interworking. c) We should have the toolchain create a new interworking relocation type. d) ? -- Tixy