[PATCH REPOST] ARM: Thumb-2: Relax relocation requirements for non-function symbols

[tixy@yxit.co.uk (Tixy)]

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 <asm/uaccess.h>.
> 
> 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