=== environment ==================================================== The bug can be replicated with any of listed GDB versions: $ arm-none-eabi-gdb -v GNU gdb (GDB) 12.0.50.20211210-git ... (gdb) show configuration This GDB was configured as follows: configure --host=i686-pc-linux-gnu --target=arm-none-eabi --with-auto-load-dir=$debugdir:$datadir/auto-load --with-auto-load-safe-path=$debugdir:$datadir/auto-load --with-expat --with-gdb-datadir=/usr/local/share/gdb (relocatable) --with-jit-reader-dir=/usr/local/lib/gdb (relocatable) --without-libunwind-ia64 --with-lzma --without-babeltrace --without-intel-pt --without-mpfr --without-xxhash --with-python=/usr --with-python-libdir=/usr/lib --without-debuginfod --without-guile --disable-source-highlight --with-separate-debug-dir=/usr/local/lib/debug (relocatable) $ gdb-multiarch -v GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2 Windows> arm-none-eabi-gdb.exe GNU gdb (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 8.3.0.20190709-git OpenOCD compiled from latest git master used as GDB server. STM32G474, a Cortex-M4 device. Any Cortex-M device can be used. A test application (an ordinary blink) with a standard startup is loaded to the device flash. === how to reproduce =============================================== start GDB server $ openocd -f interface/cmsis-dap.cfg -f target/stm32g4x.cfg start GDB in second terminal $ arm-none-eabi-gdb blink.elf (gdb) target extended-remote localhost:3333 Reset the device and halt it: (gdb) monitor reset halt target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08000e14 msp: 0x20020000 Step by one instruction to re-read GDB register cache: (gdb) stepi Check registers, LR should be 0xffffffff after reset: (gdb) info registers ... sp 0x20020000 0x20020000 lr 0xffffffff -1 pc 0x8000e16 0x8000e16 xPSR 0x1000000 16777216 ... (gdb) set debug remote Issue 'advance' command: (gdb) advance main [remote] Sending packet: $mfffffffe,2#fa [remote] Packet received: 0000 [remote] Sending packet: $mfffffffe,2#fa [remote] Packet received: 0000 [remote] Sending packet: $m8000526,2#30 [remote] Packet received: 2046 [remote] Sending packet: $Z1,8000526,2#7a [remote] Packet received: OK [remote] packet_ok: Packet Z1 (hardware-breakpoint) is supported [remote] Sending packet: $Z0,fffffffe,2#43 [remote] Packet received: E0E [remote] packet_ok: Packet Z0 (software-breakpoint) is supported Warning: Cannot insert breakpoint 0. Cannot access memory at address 0xfffffffe Command aborted. (gdb) Relevant messages from OpenOCD: Error: Failed to read memory at 0xfffff000 Error: can't add breakpoint: unknown reason === expected behavior ============================================== GDB should not set breakpoint at 0xfffffffe. The LR reg does not contain an execution address but a magic value. === analysis ======================================================= The offending breakpoint should be set at return address to caller function. The magic value 0xffffffff in LR indicates there is no caller (return to this address would lock up the CPU). Similar behaviour of 'advance' and 'until' is observed in an exception handler routine. In this case LR contains e.g. 0xfffffff1 and GDB tries to se a breakpoint at 0xfffffff0. It should use a return value stacked by exception instead. See gdb/breakpoint.c:11162 void until_break_command (const char *arg, ...) ------------------------------------------ frame = get_selected_frame (NULL); frame_gdbarch = get_frame_arch (frame); ... caller_frame_id = frame_unwind_caller_id (frame); ... if (frame_id_p (caller_frame_id)) { ... sal2 = find_pc_line (frame_unwind_caller_pc (frame), 0); sal2.pc = frame_unwind_caller_pc (frame); caller_gdbarch = frame_unwind_caller_arch (frame); breakpoint_up caller_breakpoint = set_momentary_breakpoint (caller_gdbarch, sal2, caller_frame_id, bp_until); ----------------------------------------- The breakpoint address is directly derived from the current frame by frame_unwind_caller_pc () without any effort to find out the type of previous frame, to skip not suitable frames etc... Compare it to the code used for command 'finish' which honours SIGTRAMP_FRAME correctly. gdb/infcmd.c:1706 ----------------------------------------- /* Skip frames for "finish". */ static struct frame_info * skip_finish_frames (struct frame_info *frame) { struct frame_info *start; do { start = frame; frame = skip_tailcall_frames (frame); if (frame == NULL) break; frame = skip_unwritable_frames (frame); if (frame == NULL) break; } while (start != frame); return frame; } ----------------------------------------- And the relevant part of finish_command (): ----------------------------------------- frame = skip_finish_frames (frame); if (frame == NULL) error (_("Cannot find the caller frame.")); finish_forward (sm, frame); ----------------------------------------- where finish_forward () sets set_momentary_breakpoint() at address get_frame_pc (frame); It looks like 'finish' command was adapted to handle SIGTRAMP_FRAMEs but 'advance' and 'until' were missed.
At first I thought that the solution proposed for https://sourceware.org/bugzilla/show_bug.cgi?id=28549 would help here as well. But no luck, even if LR 0xffffffff is recognised as SIGTRAMP, 'advance'/'until' does not care of it.
Created attachment 13855 [details] until_break_command modified for Cortex-M SIGTRAMP_FRAME
Hi Tomas. Is this addressed by your other patch?
(In reply to Luis Machado from comment #3) > Hi Tomas. Is this addressed by your other patch? No, as the comment 1 explains. I will check if the problem still exist in current dev version.
GNU gdb (GDB) 13.0.50.20221012-git has the same problem. The proposed patch depends on the lockup unwinder https://sourceware.org/bugzilla/attachment.cgi?id=13853 Without it the caller frame is missdetected as arm stub @ 0xfffffffe and gdb wants to set temporary breakpoint at that address. (gdb) adv main [frame] get_prev_frame_always_1: enter [frame] get_prev_frame_always_1: this_frame=0 [frame] get_prev_frame_raw: -> {level=1,type=<unknown>,unwinder=<unknown>,pc=<unknown>,id=<not computed>,func=<unknown>} [frame] compute_frame_id: enter [frame] compute_frame_id: fi=1 [frame] frame_unwind_find_by_frame: enter [frame] frame_unwind_find_by_frame: this_frame=1 [frame] frame_unwind_arch: next_frame=0 -> armv7e-m [frame] frame_unwind_try_unwinder: trying unwinder "dummy" [frame] frame_unwind_try_unwinder: no [frame] frame_unwind_try_unwinder: trying unwinder "dwarf2 tailcall" [frame] frame_unwind_try_unwinder: no [frame] frame_unwind_try_unwinder: trying unwinder "inline" [frame] frame_unwind_register_value: enter [frame] frame_unwind_register_value: frame=0, regnum=15(pc) [frame] frame_unwind_register_value: enter [frame] frame_unwind_register_value: frame=0, regnum=14(lr) [frame] frame_id_p: l={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] frame_id_p: l={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] operator==: l={stack=<sentinel>,!code,special=0x0000000000000000}, r={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] frame_unwind_register_value: enter [frame] frame_unwind_register_value: frame=-1, regnum=14(lr) [frame] frame_unwind_register_value: -> register=14 bytes=[ffffffff] [frame] frame_unwind_register_value: exit [frame] frame_id_p: l={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] operator==: l={stack=<sentinel>,!code,special=0x0000000000000000}, r={stack=<sentinel>,!code,special=0x0000000000000000} -> 1 [frame] get_prev_frame_always_1: enter [frame] get_prev_frame_always_1: this_frame=-1 [frame] get_prev_frame_always_1: -> {level=0,type=NORMAL_FRAME,unwinder="arm prologue",pc=0x4e2,id={stack=0x20010000,code=0x00000000000004e0,!special},func=0x4e0} // cached [frame] get_prev_frame_always_1: exit [frame] value_fetch_lazy_register: (frame=0, regnum=14(lr), ...) -> register=14 bytes=[ffffffff] [frame] frame_unwind_register_value: -> register=14 bytes=[ffffffff] [frame] frame_unwind_register_value: exit [frame] frame_unwind_register_value: -> computed bytes=[feffffff] [frame] frame_unwind_register_value: exit [frame] frame_unwind_pc: this_frame=0 -> 0xfffffffe [frame] frame_unwind_try_unwinder: no [frame] frame_unwind_try_unwinder: trying unwinder "jit" [frame] frame_unwind_try_unwinder: no [frame] frame_unwind_try_unwinder: trying unwinder "arm m exception" [frame] frame_unwind_try_unwinder: no [frame] frame_unwind_try_unwinder: trying unwinder "arm stub" [frame] frame_unwind_try_unwinder: yes [frame] frame_unwind_find_by_frame: exit [frame] frame_unwind_register_value: enter [frame] frame_unwind_register_value: frame=0, regnum=13(sp) [frame] frame_unwind_register_value: -> computed bytes=[00000120] [frame] frame_unwind_register_value: exit [frame] frame_unwind_register_value: enter [frame] frame_unwind_register_value: frame=0, regnum=91(msp) [frame] frame_unwind_register_value: -> computed bytes=[00000120] [frame] frame_unwind_register_value: exit [frame] frame_unwind_register_value: enter [frame] frame_unwind_register_value: frame=0, regnum=92(psp) [frame] frame_unwind_register_value: -> computed bytes=[00000000] [frame] frame_unwind_register_value: exit [frame] frame_unwind_register_value: enter [frame] frame_unwind_register_value: frame=0, regnum=13(sp) [frame] frame_unwind_register_value: -> computed bytes=[00000120] [frame] frame_unwind_register_value: exit [frame] frame_id_p: l={stack=0x20010000,code=0x00000000fffffffe,!special} -> 1 [frame] compute_frame_id: -> {stack=0x20010000,code=0x00000000fffffffe,!special} [frame] compute_frame_id: exit [frame] get_prev_frame_always_1: exit [frame] frame_id_p: l={stack=0x20010000,code=0x00000000fffffffe,!special} -> 1 [frame] frame_id_p: l={stack=0x20010000,code=0x00000000fffffffe,!special} -> 1 [frame] frame_id_p: l={!stack,!code,!special} -> 0 [frame] frame_id_p: l={!stack,!code,!special} -> 0 [frame] frame_id_p: l={!stack,!code,!special} -> 0 [frame] frame_id_p: l={!stack,!code,!special} -> 0 [frame] frame_id_p: l={!stack,!code,!special} -> 0 [frame] frame_id_p: l={!stack,!code,!special} -> 0 [frame] frame_id_p: l={!stack,!code,!special} -> 0 [frame] frame_id_p: l={!stack,!code,!special} -> 0 Note: automatically using hardware breakpoints for read-only addresses. [frame] frame_id_p: l={!stack,!code,!special} -> 0 Warning: Cannot insert breakpoint 0. Cannot access memory at address 0xfffffffe Command aborted.
Luis, I have the patch ready and tested. As I wrote it depends on [PATCH v2] gdb/arm: Terminate frame unwinding in M-profile lockup state Should I wait until the submitted one is merged or is there a faster way?
Hi Tomas, You can send it to the mailing list and point out the dependency with the other patch. That should allow us to discuss it while the other patch is under review.
Patch under review.
Created attachment 14571 [details] testing code for STM32F4 or QEMU
Created attachment 14572 [details] testing image for STM32F4 or QEMU Use: qemu-system-arm -M netduinoplus2 -nographic -s -S -kernel tick_blink.elf
The bug can be replicated with QEMU but unlike OpenOCD QEMU silently ignores setting a breakpoint at invalid address. You should set debug remote 1 and watch for Z0 packets in remote protocol log.
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e6bdfed6f5d6d5338b552f8a07577a12d9b49279 commit e6bdfed6f5d6d5338b552f8a07577a12d9b49279 Author: Andrew Burgess <aburgess@redhat.com> Date: Thu Jan 22 17:51:11 2026 +0000 gdb: fix frame_unwind_caller_WHAT functions for inline and tail calls The 3 frame_unwind_caller_WHAT functions: + frame_unwind_caller_id + frame_unwind_caller_pc + frame_unwind_caller_arch Are, I believe, currently all broken with respect to inline and tail call functions. The Python FinishBreakpoint type creates a breakpoint in the caller function which, when triggered, indicates that the FinishBreakpoint has gone out of scope. I was writing a test for the FinishBreakpoint type which included a tail call function, and the FinishBreakpoint was being created for the tail call function frame. What I observed is that the out of scope breakpoint was never being hit. The call stack in my new test looked like this: main -> tailcall_function -> normal_function I would stop in normal_function, and then create a FinishBreakpoint for the parent (tailcall_function) frame. The FinishBreakpoint's out of scope breakpoint was being correctly placed in the 'main' function, but would never trigger. The problem is that the breakpoint placed in 'main' holds a frame-id. This frame-id is the frame in which the breakpoint should trigger. This frame-id exists to prevent premature stops due to recursion. But in this case, when the breakpoint in 'main' was hit, despite no recursion having occurred, the frame-id didn't match, and so the breakpoint was ignored. The problem is that in bpfinishpy_init we call frame_unwind_caller_id to compute the frame-id of the frame in which we should stop, and frame_unwind_caller_id was returning the wrong frame-id. As far as I can tell frame_unwind_caller_id has been broken since it was updated for inline functions in commit edb3359dff90ef8a. The frame_unwind_caller_id function, and all the frame_unwind_caller_WHAT functions, are intended to return the previous frame, but should skip over any inline, or tail call frames. Let's look at an example call stack: #0 A // A normal function. #1 B // An inline function. #2 C // An inline function. #3 D // A normal function. #4 E // A normal function. Starting from #0, a normal function, frame_unwind_caller_id, should return the frame-id for #3, and this is what happens. But if we start in #1 and call frame_unwind_caller_id, then we should still return the frame-id for #3, but this is not what happens. Instead we return the frame-id for #4, skipping a frame. The problem is that frame_unwind_caller_id starts by calling skip_artificial_frames, which calls get_prev_frame_always until we reach a non-inline (or non-tail call) frame, this moves us from #1 to Then, back in frame_unwind_caller_id we call get_prev_frame_always, which moves us to #4. Then frame_unwind_caller_id finishes with a call to skip_artificial_frames, this could potentially result in additional frames being skipped, but in my example above this isn't the case. The problem here is that if skip_artificial_frames skips anything, then we have already unwound to the caller frame, and the get_prev_frame_always call in frame_unwind_caller_id is unnecessary. I propose to add a new helper function frame_unwind_caller_frame, which should do the correct thing; it unwinds one frame and then calls skip_artificial_frames. This should do exactly what is needed. Then all the frame_unwind_caller_WHAT functions will be updated to use this helper function, and just extract the required property from the resulting frame. With this fix in place I could then write the FinishBreakpoint test, which now works. I took a look for other places where frame_unwind_caller_id is used and spotted that the 'until' command does much the same thing, placing a breakpoint in the caller frame. As predicted, the 'until' command is also broken when used within a tail call frame. This patch fixes that issue too. There's also a test for the until command. The bug PR gdb/28683 seems to describe this exact problem with a specific AArch64 case given. I haven't actually setup the environment needed to test this bug, but I'm reasonably sure that this patch will fix the bug. Even if it doesn't then it's certainly related and worth linking into the bug report. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28683 Approved-By: Tom Tromey <tom@tromey.com>
The described problem was mitigated somewhere between v13 and v16.2 At least gdb v16.2 does not try to set breakpoint at wrong 0xfffffffe address. No change observed in gdb compiled from the actual git source with and without "gdb: fix frame_unwind_caller_WHAT functions for inline and tail calls" patch. Thanks anyway.