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

[Dave Martin]

On Wed, Jun 01, 2011 at 02:04:36PM +0100, Tixy wrote:
> 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 ;-)

The tools generate B and BL for branches whose target is unknown
and for which a relocation is needed.  These get accompanying
relocations which will cause the instructions to get rewritten
as BLX (or veneers will be introduced) is interworking is
discovered to be necessary at link time.

BX and BLX instructions are not relocatable: basically, these
instructions should only exist when the target instruction set
is known; i.e. after relocation processing, or for hard internal
fixups which don't need any further relocation.

This summarises the possibilities:

	Source ISA	Target ISA	instruction
	ARM		ARM		B or BL
	ARM		Thumb		BX or BLX
	ARM		undefined	B or BL, + relocation
	Thumb		ARM		BX or BLX
	Thumb		Thumb		B or BL
	Thumb		undefined	B or BL, + relocation

(Note that as a consequence of the ARM EABI, a relocation
referencing an undefined symbol always has an undefined target
ISA.  I think EABI has no concept of a non-interworking
relocatable branch.)

Since the kernel doesn't pretend to cope with interworking
internally, we don't need to handle BX and BLX generation for
relocation purposes.  There is much assembler code in the kernel
which is broken (or at least, not explicitly intended to work)
for interworking, so we can't easily support that; nor is there
any great benefit in supporting it.

So, we should never turn a B or BL into BX/BLX when applying
relocations in kernel modules; and if it looks like we need
to (because the target symbol has the wrong ISA) then that's
a bug.

The patch attempts to resolve a bogus false positive of that
check.

> b) We should remove the checks in the relocation code preventing
> interworking.

The main usefulness of these checks was to flag up accidental
loading of Thumb-2 modules into ARM kernels and vice-versa.
We now have information in the module version magic to avoid
that, but I think it's still sensible to sanity-check these
relocations when loading modules.  It doesn't add much code,
and people may still occasionally get things wrong.

> c) We should have the toolchain create a new interworking relocation
> type.

There should be no need, as described above.

Cheers
---Dave