[PATCH] D33436: [ARM] Create relocation for Thumb functions calling ARM fns.

Rafael Avila de Espindola via llvm-commits llvm-commits at lists.llvm.org
Wed May 24 16:12:56 PDT 2017


Peter Smith via Phabricator <reviews at reviews.llvm.org> writes:

> The ABI only permits a linker to do interworking (such as changing a BL to BLX) for a relocation if the symbol has type STT_FUNC and the relocation is one of R_ARM_CALL, R_ARM_JUMP24, R_ARM_THM_CALL, R_ARM_THM_JUMP22, R_ARM_THM_JUMP19, which match ARM BL/BLX, ARM B, Thumb BL/BLX, Thumb B.w, Thumb B.w<cc>. The narrow 16-bit Thumb branch instructions are excluded. The linker should give an error messages if it detects that an ARM/Thumb state change is required outside of these conditions. So I think that adding a relocation wouldn't make correct code generated by the assembler incorrect, and it would give the linker a chance to detect the error. I note that for ARM state callers we just mark all the branch type relocations as IsResolved=false, and I suggest we do the same for wide Thumb branch type relocations as well.
>
> If there is a BL/BLX to an internal label that doesn't have type STT_FUNC (and may not have the thumb bit set) then the linker is not supposed to try and do interworking. According to the ABI it is the programmers responsibility to be in the correct ARM/Thumb state before writing the instruction in this case. I think the ideal behaviour would be to issue an error message, but we could rely on the linker to do it.

But given simple assembly like

----------------------------
	.text
	.syntax unified
	.globl	f
	.p2align	1
	.type	f,%function
	.code	16
	.thumb_func
f:
foo:
	nop
bar:
---------------------------

only f is STT_THUMB and has the lsb set:

     2: 00000002     0 NOTYPE  LOCAL  DEFAULT    2 bar
     3: 00000000     0 NOTYPE  LOCAL  DEFAULT    2 foo
     4: 00000001     0 FUNC    GLOBAL DEFAULT    2 f

Is that a bug in the assembler or invalid assembly? Should the linker
report an error if there was a branch to foo or bar?

Cheers,
Rafael


More information about the llvm-commits mailing list