[llvm][ARM] Unable to use .cantunwind (and similar directives) in inline assembly

[alexrp]

void _start(void)
{
    asm volatile (".cantunwind");
}

❯ arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (Ubuntu 13.2.0-4ubuntu3) 13.2.0
❯ arm-linux-gnueabihf-gcc test.c -nostdlib -fasynchronous-unwind-tables
❯ clang --version
clang version 19.1.2 (git@github.com:llvm/llvm-project.git d5498c39fe6a17e271ad5a02917103445eb89373)
❯ clang --target=arm-linux-gnueabihf test.c -nostdlib -fasynchronous-unwind-tables
test.c:3:19: error: .fnstart must precede .cantunwind directive
    3 |     asm volatile (".cantunwind");
      |                   ^
<inline asm>:1:2: note: instantiated into assembly here
    1 |         .cantunwind
      |         ^
1 error generated.

I would guess that .fnstart/.fnend is lacking similar handling to .cfi_startproc/.cfi_endproc in the integrated assembler?

[llvmbot]

@llvm/issue-subscribers-backend-arm

Author: Alex Rønne Petersen (alexrp)

```c void _start(void) { asm volatile (".cantunwind"); } ```

❯ arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (Ubuntu 13.2.0-4ubuntu3) 13.2.0
❯ arm-linux-gnueabihf-gcc test.c -nostdlib -fasynchronous-unwind-tables
❯ clang --version
clang version 19.1.2 (git@<!-- -->github.com:llvm/llvm-project.git d5498c39fe6a17e271ad5a02917103445eb89373)
❯ clang --target=arm-linux-gnueabihf test.c -nostdlib -fasynchronous-unwind-tables
test.c:3:19: error: .fnstart must precede .cantunwind directive
    3 |     asm volatile (".cantunwind");
      |                   ^
&lt;inline asm&gt;:1:2: note: instantiated into assembly here
    1 |         .cantunwind
      |         ^
1 error generated.

I would guess that .fnstart/.fnend is lacking similar handling to .cfi_startproc/.cfi_endproc in the integrated assembler?

[efriedma-quic]

If you define a complete function inside an asm block, .cantunwind should work. If you're writing code within a function, that's more restricted: inline asm blocks are parsed separately. It isn't just blindly interpolated into the function, so you can't modify a function like this.

__attribute__((nouwtable)) should do what you want.

[alexrp]

Just to clarify: I'm using C in the example, but I actually ran into the issue in Zig.

If you define a complete function inside an asm block, .cantunwind should work. If you're writing code within a function, that's more restricted: inline asm blocks are parsed separately. It isn't just blindly interpolated into the function, so you can't modify a function like this.

I don't quite understand why this would have to be the case for .cantunwind when e.g. .cfi_undefined and other similar directives work fine in inline assembly?

__attribute__((nouwtable)) should do what you want.

(We don't have an __attribute__((nouwtable)) equivalent in Zig.)

[efriedma-quic]

.cfi_undefined outside a function is silently discarded instead of emitting an error. Maybe we could do the same for .cantunwind, I guess, but it seems sort of weird.

We don't make promises about the exact structure of emitted assembly outside the asm block, though, so I wouldn't encourage using exception-handling directives like that in any case.

[alexrp]

.cfi_undefined outside a function is silently discarded instead of emitting an error.

That doesn't seem right. This:

int main(void)
{
    asm volatile (".cfi_undefined %r13");
    asm volatile (".cfi_undefined %r14");
    asm volatile (".cfi_undefined %r15");
}

compiled with clang -fexceptions gets me:

00000070 00000020 00000074 FDE cie=00000000 pc=00001130...00001138
  Format:       DWARF32
  DW_CFA_advance_loc: 1 to 0x1131
  DW_CFA_def_cfa_offset: +16
  DW_CFA_offset: RBP -16
  DW_CFA_advance_loc: 3 to 0x1134
  DW_CFA_def_cfa_register: RBP
  DW_CFA_undefined: R13
  DW_CFA_undefined: R14
  DW_CFA_undefined: R15
  DW_CFA_advance_loc: 3 to 0x1137
  DW_CFA_def_cfa: RSP +8
  DW_CFA_nop:

  0x1130: CFA=RSP+8: RIP=[CFA-8]
  0x1131: CFA=RSP+16: RBP=[CFA-16], RIP=[CFA-8]
  0x1134: CFA=RBP+16: RBP=[CFA-16], R13=undefined, R14=undefined, R15=undefined, RIP=[CFA-8]
  0x1137: CFA=RSP+8: RBP=[CFA-16], R13=undefined, R14=undefined, R15=undefined, RIP=[CFA-8]

[efriedma-quic]

To be more precise:

There are two layers involved here: the "parser", and the "streamer". The parser converts text into an internal representation, and the streamer processes it. For stuff that isn't inline asm, the compiler normally just pokes the streamer directly.

The error checking here is part of the "parser". The Arm asm parser does its own tracking for whether there's a .fnstart. The compiler's .fnstart doesn't use the asm parser to emit .fnstart (it skips straight to the streamer), so the asm parser thinks there's a missing .fnstart, so it emits an error.

The generic CFI parsing doesn't track anything; it just throws it all at the asm streamer. And the streamer will silently discard directives. But it will also allow mixing up directives with the ones the compiler emits internally.

Maybe there's some solution where we can make the parser cooperate with the streamer to emit error messages.

[alexrp]

Ah, I see what you mean now. That makes sense.

If my understanding of the parser/printer/streamer abstractions is correct (it very well might not be!), then it should be sufficient to add state tracking for emitFnStart()/emitFnEnd() calls to ARMTargetStreamer such that ARMAsmParser can query it. It might even make sense for most of the state tracking related to EH directives in ARMAsmParser to be moved there. Does this sound right?