[all-commits] [llvm/llvm-project] d97f17: [MC][ARM] Fix crash when assembling Thumb 'movs r0...

[Simon Tatham via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: d97f17a95982bab49ecdfb9b45ef3c7d7e3d143e
      https://github.com/llvm/llvm-project/commit/d97f17a95982bab49ecdfb9b45ef3c7d7e3d143e
  Author: Simon Tatham <simon.tatham at arm.com>
  Date:   2024-11-14 (Thu, 14 Nov 2024)

  Changed paths:
    M llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
    A llvm/test/MC/ARM/lower-upper-errors-2.s
    A llvm/test/MC/ARM/lower-upper-errors.s

  Log Message:
  -----------
  [MC][ARM] Fix crash when assembling Thumb 'movs r0,#foo'. (#115026)

If the assembler sees this instruction, understanding `foo` to be an
external symbol, there's no relocation it can write that will put the
whole value of `foo` into the 8-bit immediate field of the 16-bit Thumb
add instruction. So it should report an error message pointing at the
source line, and in LLVM 18, it did exactly that. But now the error is
not reported, due to an indexing error in the operand list in
`validateInstruction`, and instead the code continues to attempt
assembly, ending up aborting at the `llvm_unreachable` at the end of
`getHiLoImmOpValue`.

In this commit I've fixed the index in the `ARM::tMOVi8` case of
`validateInstruction`, and also the one for `tADDi8` which must cope
with either the 2- or 3-operand form in the input assembly source. But
also, while writing the test, I found that if you assemble for Armv7-M
instead of Armv6-M, the instruction has opcode `t2ADDri` when it goes
through `validateInstruction`, and only turns into `tMOVi8` later in
`processInstruction`. Then it's too late for `validateInstruction` to
report that error. So I've adjusted `processInstruction` to spot that
case and inhibit the conversion.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications