On Windows ARM64, intrinsic __debugbreak should be compiled into brk #0xF000 which is different from llvm intrinsic debugtrap as brk #0. This change fixes this by transforming __debugbreak to the expected inline assembly in Clang.
Diff Detail
- Repository
- rC Clang
Event Timeline
I think it would be preferable to make llvm.debugtrap emit brk #0xF000 on aarch64-windows-*, so other frontends (Rust etc) get the right behavior by default. Right now, AArch64 doesn't do anything special for DEBUGTRAP, so we get the default behavior of llvm.trap.
Is this BRK #0xF000 convention universal to all OSs, or is it a specific convention for Windows debuggers?
I looked at llvm.debugtrap but I am not sure the side-effect of that fix, like could there be some other ABI (mingw, etc.) on Windows ARM64 which expects DEBUGTRAP to be the same as Android/Linux.
I think this BRK #0xF000 convention is only for Windows debugger and exception handler, such as we define __fastfail in the same way with different operand, not universal for all OSs.
Even if BRK #0xF000 is a Windows convention, it's still possible for ISel to select different instructions for different OSs, and I'd prefer to implement it that way.