On Thu, 28 Jan 2021 at 20:34, Nick Desaulniers <ndesaulni...@google.com> wrote:
>
> Clang's integrated assembler only accepts UAL syntax, rewrite the
> instructions that were changed by RVCTv2.1.
>
> The document "Assembly language changes after RVCTv2.1" was very
> helpful.
>
> This exposed a bug in Clang's integrated assembler, which hopefully will
> land in clang-12, but is required to test this patch with LLVM_IAS=1.
>
> Link:
> https://developer.arm.com/documentation/dui0473/c/writing-arm-assembly-language/assembly-language-changes-after-rvctv2-1
> Link: https://github.com/ClangBuiltLinux/linux/issues/1271
> Link: https://reviews.llvm.org/D95586
> Reported-by: Arnd Bergmann <a...@arndb.de>
> Signed-off-by: Nick Desaulniers <ndesaulni...@google.com>
> ---
> * Fix additonal swpvsb case in test-arm.c when __LINUX_ARM_ARCH__ < 6,
> reported by Arnd.
> * Fix arch/arm/probes/kprobes/test-thumb.c, reported by Arnd.
> * Modify the oneline to note I'm modifying test-*.c.
>
> arch/arm/probes/kprobes/test-arm.c | 290 +++++++++++++--------------
> arch/arm/probes/kprobes/test-thumb.c | 20 +-
> 2 files changed, 155 insertions(+), 155 deletions(-)
>
...
> diff --git a/arch/arm/probes/kprobes/test-thumb.c
> b/arch/arm/probes/kprobes/test-thumb.c
> index 456c181a7bfe..63277c1006b9 100644
> --- a/arch/arm/probes/kprobes/test-thumb.c
> +++ b/arch/arm/probes/kprobes/test-thumb.c
> @@ -441,21 +441,21 @@ void kprobe_thumb32_test_cases(void)
> "3: mvn r0, r0 \n\t"
> "2: nop \n\t")
>
> - TEST_RX("tbh [pc, r",7, (9f-(1f+4))>>1,"]",
> + TEST_RX("tbh [pc, r",7, (9f-(1f+4))>>1,", lsl #1]",
Why is this change needed? Are the resulting opcodes equivalent? Does
GAS infer the lsl #1 but Clang doesn't?
> "9: \n\t"
> ".short (2f-1b-4)>>1 \n\t"
> ".short (3f-1b-4)>>1 \n\t"
> "3: mvn r0, r0 \n\t"
> "2: nop \n\t")
>
> - TEST_RX("tbh [pc, r",12, ((9f-(1f+4))>>1)+1,"]",
> + TEST_RX("tbh [pc, r",12, ((9f-(1f+4))>>1)+1,", lsl #1]",
> "9: \n\t"
> ".short (2f-1b-4)>>1 \n\t"
> ".short (3f-1b-4)>>1 \n\t"
> "3: mvn r0, r0 \n\t"
> "2: nop \n\t")
>
> - TEST_RRX("tbh [r",1,9f, ", r",14,1,"]",
> + TEST_RRX("tbh [r",1,9f, ", r",14,1,", lsl #1]",
> "9: \n\t"
> ".short (2f-1b-4)>>1 \n\t"
> ".short (3f-1b-4)>>1 \n\t"
> @@ -468,15 +468,15 @@ void kprobe_thumb32_test_cases(void)
>
> TEST_UNSUPPORTED("strexb r0, r1, [r2]")
> TEST_UNSUPPORTED("strexh r0, r1, [r2]")
> - TEST_UNSUPPORTED("strexd r0, r1, [r2]")
> + TEST_UNSUPPORTED("strexd r0, r1, r2, [r2]")
> TEST_UNSUPPORTED("ldrexb r0, [r1]")
> TEST_UNSUPPORTED("ldrexh r0, [r1]")
> - TEST_UNSUPPORTED("ldrexd r0, [r1]")
> + TEST_UNSUPPORTED("ldrexd r0, r1, [r1]")
>
> TEST_GROUP("Data-processing (shifted register) and (modified
> immediate)")
>
> #define _DATA_PROCESSING32_DNM(op,s,val)
> \
> - TEST_RR(op s".w r0, r",1, VAL1,", r",2, val, "")
> \
> + TEST_RR(op s" r0, r",1, VAL1,", r",2, val, "")
> \
What is wrong with these .w suffixes? Shouldn't the assembler accept
these even on instructions that only exist in a wide encoding?
> TEST_RR(op s" r1, r",1, VAL1,", r",2, val, ", lsl #3")
> \
> TEST_RR(op s" r2, r",3, VAL1,", r",2, val, ", lsr #4")
> \
> TEST_RR(op s" r3, r",3, VAL1,", r",2, val, ", asr #5")
> \
> @@ -764,7 +764,7 @@ CONDITION_INSTRUCTIONS(22,
> TEST("nop.w")
> TEST("wfi.w")
> TEST_SUPPORTED("wfe.w")
> - TEST_UNSUPPORTED("dbg.w #0")
> + TEST_UNSUPPORTED("dbg #0")
>
> TEST_UNSUPPORTED("clrex")
> TEST_UNSUPPORTED("dsb")
> @@ -790,9 +790,9 @@ CONDITION_INSTRUCTIONS(22,
> TEST_BB( "b.w 2b")
> TEST_BF_X("b.w 2f", SPACE_0x1000)
>
> - TEST_BF( "bl.w 2f")
> - TEST_BB( "bl.w 2b")
> - TEST_BB_X("bl.w 2b", SPACE_0x1000)
> + TEST_BF( "bl 2f")
> + TEST_BB( "bl 2b")
> + TEST_BB_X("bl 2b", SPACE_0x1000)
>
> TEST_X( "blx __dummy_arm_subroutine",
> ".arm \n\t"
> --
> 2.30.0.365.g02bc693789-goog
>
