clang ias, thumb2: proc-v7.S:85:60: error: branch target out of range

[arndb]

Building a thumb2-enabled arm32 kernel with clang ias and CONFIG_SMP_ON_UP, I get a couple of errors like

arch/arm/mm/proc-v7.S:85:60: error: branch target out of range
.pushsection ".alt.smp.init", "a" ; .long 9998b - . ; b.w . + (1f - 9998b) ; .popsection

The underlying code looks like

#ifdef CONFIG_SMP
#define ALT_SMP(instr...)                                       \
9998:   instr
/*
 * Note: if you get assembler errors from ALT_UP() when building with
 * CONFIG_THUMB2_KERNEL, you almost certainly need to use
 * ALT_SMP( W(instr) ... )
 */
#define ALT_UP(instr...)                                        \
        .pushsection ".alt.smp.init", "a"                       ;\
        .long   9998b - .                                       ;\
9997:   instr                                                   ;\
        .if . - 9997b == 2                                      ;\
                nop                                             ;\
        .endif                                                  ;\
        .if . - 9997b != 4                                      ;\
                .error "ALT_UP() content must assemble to exactly 4 bytes";\
        .endif                                                  ;\
        .popsection
#define ALT_UP_B(label)                                 \
        .pushsection ".alt.smp.init", "a"                       ;\
        .long   9998b - .                                       ;\
        W(b)    . + (label - 9998b)                                     ;\
        .popsection
#else
#define ALT_SMP(instr...)
#define ALT_UP(instr...) instr
#define ALT_UP_B(label) b label
#endif

and this was recently changed with commit 450abd3 ("ARM: kernel: use relative
references for UP/SMP alternatives").

[nickdesaulniers]

cc @jcai19

This is the issue observed in ALT_UP_B in arch/arm/include/asm/assembler.h with CONFIG_THUMB2_KERNEL.

[nickdesaulniers]

Smaller test case (requires https://reviews.llvm.org/D95872)

.syntax unified
9998:
        nop.w @ don't use adr_l inside ALT_SMP()
.pushsection ".alt.smp.init", "a"
.long 9998b - .
        b.w . + (1f - 9998b)
.popsection
1:

$ clang --target=arm-linux-gnueabi -Wa,-mthumb -Wa,-march=armv7-a foo.s
foo.s:6:5: error: branch target out of range
b.w . + (1f - 9998b)
    ^

vs

$ arm-linux-gnueabi-as -mthumb -march=armv7-a foo.s
$ arm-linux-gnueabi-objdump -Dr a.out
...
Disassembly of section .text:

00000000 <.text>:
   0:   f3af 8000       nop.w

Disassembly of section .alt.smp.init:

00000000 <.alt.smp.init>:
   0:   00000000        andeq   r0, r0, r0
                        0: R_ARM_REL32  .text
   4:   f000 b800       b.w     8 <.alt.smp.init+0x8>
...

[nickdesaulniers]

seems like target specific parsing, since

9998:
  jmp . + (1f - 9998b + 2)
1:
  nop

works for x86, but

.syntax unified

9998:
  b.w . + (1f - 9998b + 2)
1:
  nop

fails for clang --target=arm-linux-gnueabi -Wa,-mthumb -Wa,-march=armv7-a.

Looks like calls to parseExpression in parseOperand are failing. I wonder why? cc @DavidSpickett Perhaps following how X86AsmParser resolves this might shed some more light.

[jcai19]

Thanks for the reduced test case. I also reproduced the issue with llvm-mc.

$ cat foo.s
.syntax unified

9998:
  b.w . + (1f - 9998b + 2)
1:
  nop

$ llvm-mc -triple=thumbv7a-linux-gnueabi -filetype=obj foo.s -o clang.o
foo.s:4:7: error: branch target out of range
  b.w . + (1f - 9998b + 2)

[jcai19]

Further reduced test case:

$ cat foo.s
.syntax unified

9998:
  b.w . + 2

$ llvm-mc -triple=thumbv7a-linux-gnueabi -filetype=obj foo.s -o clang.o
foo.s:4:7: error: branch target out of range
  b.w . + 2

But if I further reduce operand of the jump instruction then the test case works.

$ cat foo.s
.syntax unified

9998:
  b.w .

$ llvm-mc -triple=thumbv7a-linux-gnueabi -filetype=obj foo.s -o clang.o
$ echo $?
0
$ arm-linux-gnueabihf-objdump -d clang.o
clang.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <.text>:
   0:	f7ff bffe 	b.w	0 <.text>

The difference is caused by one particular line (https://llvm.org/doxygen/ARMAsmParser_8cpp_source.html#l01072) of code in ARMOperand::isSignedOffset, which returns opposite boolean values for the two cases. Will do more investigation and see if we can handle the former casse by fixing this line in LLVM.

[jcai19]

So the fundamental issue here is that LLVM ARM backend tries to validate the range of branch targets before symbolic values are resolved (i.e. before the layout of fragments are finalized). LLVM also validates the range after the values are known, so disabling the first check for symbolic expressions (which they already do if the expression is a single symbol) seems to work for me. I have a patch locally but it seems LLVM Phabricator is down for the moment. Will send it for review once it comes back.

[jcai19]

LLVM patch sent: https://reviews.llvm.org/D97501