I first noticed this one on aarch64-linux-gnu, but it also reproduces on x86_64-linux-gnu. It is very likely this will reproduce on any native targets that implement/override the low_prepare_to_resume method and throw an error from it.

Follows a reproducer. The binary can be any dummy binary with a main function (I used a hello world).

---

./gdb/gdb /tmp/hello -ex "start" -ex "b" -ex "watch *0xffffffffdeadbeef"
GNU gdb (GDB) 12.0.50.20211119-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /tmp/hello...
Temporary breakpoint 1 at 0x115c: file /tmp/hello.c, line 5.
Starting program: /tmp/hello 

Temporary breakpoint 1, main (argc=1, argv=0x7fffffffe558) at /tmp/hello.c:5
5	  printf ("Hello world!\n");
Breakpoint 2 at 0x55555555515c: file /tmp/hello.c, line 5.
Hardware watchpoint 3: *0xffffffffdeadbeef
(gdb) c
Continuing.
Couldn't write debug register: Invalid argument.
(gdb) bt
#0  0x0000555555555062 in _start ()
(gdb) 

---

So there are a few things going on:

1 - We are stopped on top of a breakpoint.
2 - Moving the program means we need to step over such a breakpoint.
3 - The target supports displaced stepping, and so stepping over the breakpoint means doing a displaced stepping.
4 - We have an impossible hardware watchpoint that will trigger an error when we attempt to move the program and thus write the proper debug register information.
5 - The code in infrun.c:keep_going_pass_signal, more specifically when it calls "resume", is not guarded against faults. "resume_1" is guarded, but doesn't handle this situation properly like infrun.c:keep_going_pass_signal does when calling "insert_breakpoints".

As shown above, GDB gets an unexpected error from the low_prepare_to_resume method, goes through infrun.c:resume_1's catch block and then re-throws the exception. So GDB never attempts to rollback the state of displaced stepping, leaving the PC pointing at the scratch pad location.

If we disable displaced stepping, we have the following:

---
./gdb/gdb /tmp/hello -ex "set displaced-stepping off" -ex "start" -ex "b" -ex "watch *0xffffffffdeadbeef"
GNU gdb (GDB) 12.0.50.20211119-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /tmp/hello...
Temporary breakpoint 1 at 0x115c: file /tmp/hello.c, line 5.
Starting program: /tmp/hello 

Temporary breakpoint 1, main (argc=1, argv=0x7fffffffe558) at /tmp/hello.c:5
5	  printf ("Hello world!\n");
Breakpoint 2 at 0x55555555515c: file /tmp/hello.c, line 5.
Hardware watchpoint 3: *0xffffffffdeadbeef
(gdb) c
Continuing.
Couldn't write debug register: Invalid argument.
(gdb) bt
#0  main (argc=1, argv=0x7fffffffe558) at /tmp/hello.c:5
(gdb) 
---

I thought about this a little, and adding a displaced_step_finish call in one of the catch blocks of either resume/resume_1 seems to work. But I haven't done further testing with it. It didn't seem to have any regressions.

The documentation of low_prepare_to_resume doesn't mention anything about implementations being forbidden to throw, so I guess this is an oversight.