Re: [REGRESSION] 32-bit ARM's BKPT instruction no longer works
From: Russell King (Oracle)
Date: Sun Jun 21 2026 - 16:20:09 EST
On Sun, Jun 21, 2026 at 07:15:27PM +0000, slipher wrote:
> Consider the C program for 32-bit ARM architectures:
>
> int main() {
> __asm__ __volatile__ ("BKPT");
> return 0;
> }
>
>
> Expected behavior is that this raises SIGTRAP. Since Linux 6.10 this no
> longer happens; instead execution perpetually resumes at the same
> instruction, using 100% of CPU. It does not matter whether GDB is
> attached. I have tested with an armv7l CPU, but I imagine any other
> variants with the BKPT instruction would be equally affected.
Looking at the code, I doubt this has ever cleanly raised SIGTRAP (can
you check whether it does in kernels without c3f89986fde please?)
What I suspect instead is you get an "Unhandled ... abort" instead
and the program forcefully killed as hw_breakpoint_pending() would
have ARM_DSCR_MOE(dscr) == 3, and the switch() would set ret = 1.
That triggers the fault handlers in arch/arm/mm/fault.c to
complain bitterly, and forced a SIGTRAP to the program to kill it
off. No resumption from an unhandled trap is expected.
BKPT was added in later versions of the architecture. In order for
32-bit ARM to have functional breakpoints with older versions of the
architecture, we had to invent our own breakpoint instruction using
what was available in the reference manuals of the time - and this
needed to be maintained in a forwards compatible manner. Sadly, Arm
Ltd were late to the party.
The ARM mode breakpoint instructions that were chosen were 0xe7f001f0
and 0xde01 for Thumb. These cause a SIGTRAP with a TRAP_BRKPT code.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!