Re: [REGRESSION] 32-bit ARM's BKPT instruction no longer works

[Russell King <linux@armlinux.org.uk>]

On Tue, Jun 23, 2026 at 03:35:05PM +0200, Linus Walleij wrote:
> On Tue, Jun 23, 2026 at 11:48 AM Russell King <linux@armlinux.org.uk> wrote:
> 
> > Let me also be clear: I expect Linus W to fix this
> 
> I'll try!
> 
> I guess the offending commit is:
> commit c3f89986fde7bb9ccc86a901bf28e1f7d69fc3b3
> "ARM: 9391/2: hw_breakpoint: Handle CFI breakpoints"
> 
> > I suspect that the CFI fault code was a decision by compiler authors,
> > but I can't say because I don't have a setup that generates the code
> > for CFI.
> 
> Yep, the LLVM implementers chose breakpoint code 0x03:
> I think it comes from here:
> https://llvm.org/doxygen/ARMAsmPrinter_8cpp_source.html
> Line 1536-37:
> unsigned AddrIndex = TRI->getEncodingValue(AddrReg);
> unsigned ESR = 0x8000 | (31 << 5) | (AddrIndex & 31);

Presumably it's actually line 1618:

  EmitToStreamer(*OutStreamer, MCInstBuilder(ARM::UDF).addImm(ESR));

and if ARM::UDF happens to be BKPT rather than the UDF instruction
(maybe this is configurable? Can you check what this is and whether
it is?)

If LLVM is also using the BKPT instruction, then we have a compiler
binary interface vs userspace program using BKPT issue...

Given the "no regressions" rule, this means we can't ever support the
LLVM CFI BKPT usage unless LLVM changes... and that creates a
regression for the compiler people, because they have to care about
more than just the Linux kernel and one userspace program.

I don't see a clean solution to this, other than saying "No!" to
LLVM people and backing out your change.

Maybe our nameless regressionreporter can find out which BKPT
instruction(s) is/are actually being used (it takes an immediate
value.)

This makes me want the old days of Acorn Computers back, because
*they* were sensible when it comes to instruction sets and fields
such as the immediate in SWI/SVC - they had the foresight to state
that the immediate would be broken up into fields which included an
OS identifier, effectively separating the numberspace so that
different OS etc avoid clashing with that instruction. Linux had
a time when it supported running Acorn RISC OS programs natively
as a result of that in the days of OABI. Seems to me the computer
industry just goes backwards. :/

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!