Issues with udf when assembling for Cortex-M3

[mateusz-banaszek]

When using clang to assemble for ARM Cortex-M3, I've come across 2 issues with the udf (Permanently Undefined) instruction. To illustrate:

.syntax unified

@ Issue 1
udf     #256

@ Issue 2
it eq
udfeq   #20

An attempt to assemble that using clang v19.1.5:

clang -nodefaultlibs -mcpu=cortex-m3 --target=armv7m-none-eabi ./example.s

results in 2 errors:

./example.s:4:9: error: operand must be an immediate in the range [0,255]
udf     #256
        ^
./example.s:8:1: error: instruction 'udf' is not predicable, but condition code specified
udfeq   #20
^

However, I don't see a reason to that. Arm v7-M Architecture Reference Manual shows 2 instruction encodings: T2 accepts imm16, and both accept a condition:

Encoding T1: UDF<c> #<imm8>
Encoding T2: UDF<c>.W #<imm16>

Surprisingly, the udf-thumb-2-diagnostics.s test verifies that clang does generate these errors. However, even after reviewing the 27351f2 commit which implemented udf, I still don't see a reason to that. I expect that the snippet is assembled to:

f7f0 a100   udf.w #256
bf08   it eq
de14   udfeq #20

So I expect that for Issue 1 clang chooses itself the wide encoding (as it does for, e.g., adds r0, r1, #1024 vs. adds r0, r1, #2), whereas for Issue 2 clang assembles it as the instruction accepts the condition and it is predicable (Arm v7-M Architecture Reference Manual: "UNDEFINED Indicates an instruction that generates an Undefined Instruction exception."). GCC assembles it correctly: https://godbolt.org/z/Y8q7KbzKG.

Or is there something I don't understand?

[llvmbot]

@llvm/issue-subscribers-backend-arm

Author: Mateusz Banaszek (mateusz-banaszek)

When using clang to assemble for ARM Cortex-M3, I've come across 2 issues with the `udf` (Permanently Undefined) instruction. To illustrate:

.syntax unified

@ Issue 1
udf     #<!-- -->256

@ Issue 2
it eq
udfeq   #<!-- -->20

An attempt to assemble that using clang v19.1.5:

clang -nodefaultlibs -mcpu=cortex-m3 --target=armv7m-none-eabi ./example.s

results in 2 errors:

./example.s:4:9: error: operand must be an immediate in the range [0,255]
udf     #<!-- -->256
        ^
./example.s:8:1: error: instruction 'udf' is not predicable, but condition code specified
udfeq   #<!-- -->20
^

However, I don't see a reason to that. Arm v7-M Architecture Reference Manual shows 2 instruction encodings: T2 accepts imm16, and both accept a condition:

> Encoding T1: UDF&lt;c> #&lt;imm8>
> Encoding T2: UDF&lt;c>.W #&lt;imm16>

Surprisingly, the udf-thumb-2-diagnostics.s test verifies that clang does generate these errors. However, even after reviewing the 27351f2 commit which implemented udf, I still don't see a reason to that. I expect that the snippet is assembled to:

f7f0 a100   udf.w #<!-- -->256
bf08   it eq
de14   udfeq #<!-- -->20

So I expect that for Issue 1 clang chooses itself the wide encoding (as it does for, e.g., adds r0, r1, #<!-- -->1024 vs. adds r0, r1, #<!-- -->2), whereas for Issue 2 clang assembles it as the instruction accepts the condition and it is predicable (Arm v7-M Architecture Reference Manual: "UNDEFINED Indicates an instruction that generates an Undefined Instruction exception."). GCC assembles it correctly: https://godbolt.org/z/Y8q7KbzKG.

Or is there something I don't understand?

[chestnykh]

https://developer.arm.com/documentation/ddi0406/cb/Application-Level-Architecture/Instruction-Details/Alphabetical-list-of-instructions/UDF

In Thumb mode there are two different syntax cases

1. UDF(c) imm8
2. UDF(c).W imm16
   So technically i think llvm MC layer is correct when accepting
   udf #255 and udf.w #256 in thumb mode and rejecting udf #256
udf #256 can be accepted in arm mode only.

udfeq case looks like a bug

[matrach]

In the link you've provided the Assembler Syntax below states: UDF{<c>}{<q>} {#}<imm>. Thumb2 (almost?) always documents short instructions without a suffix.

The expected behavior is explained in Standard assembler syntax fields section:

<q>
Specifies optional assembler qualifiers on the instruction. The following qualifiers are defined:

.N
Meaning narrow, specifies that the assembler must select a 16-bit encoding for the instruction. If this is not possible, an assembler error is produced.

.W
Meaning wide, specifies that the assembler must select a 32-bit encoding for the instruction. If this is not possible, an assembler error is produced.

If neither .W nor .N is specified, the assembler can select either 16-bit or 32-bit encodings. If both are available, it must select a 16-bit encoding. In a few cases, more than one encoding of the same length can be available for an instruction. The rules for selecting between such encodings are instruction-specific and are part of the instruction description.

[mateusz-banaszek]

@chestnykh, note that

https://developer.arm.com/documentation/ddi0406/cb/Application-Level-Architecture/Instruction-Details/Alphabetical-list-of-instructions/UDF

is ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition, while Cortex-M3 is ARMv7-M, so I support my reasoning with ARMv7-M Architecture Reference Manual. ARMv7-M is Thumb-only and I don't see in the documentation any difference between udf and, e.g., adds which would suggest that clang shouldn't choose itself udf.w when assembling udf #256, but should choose adds.w when assembling adds r0, r1, #1024.