public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
* [Bug breakpoints/28683] New: advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M @ 2021-12-10 20:28 tomas.vanek at fbl dot cz 2021-12-10 20:51 ` [Bug breakpoints/28683] " tomas.vanek at fbl dot cz ` (10 more replies) 0 siblings, 11 replies; 12+ messages in thread From: tomas.vanek at fbl dot cz @ 2021-12-10 20:28 UTC (permalink / raw) To: gdb-prs https://sourceware.org/bugzilla/show_bug.cgi?id=28683 Bug ID: 28683 Summary: advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M Product: gdb Version: HEAD Status: UNCONFIRMED Severity: normal Priority: P2 Component: breakpoints Assignee: unassigned at sourceware dot org Reporter: tomas.vanek at fbl dot cz Target Milestone: --- === 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. -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/28683] advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M 2021-12-10 20:28 [Bug breakpoints/28683] New: advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M tomas.vanek at fbl dot cz @ 2021-12-10 20:51 ` tomas.vanek at fbl dot cz 2021-12-14 17:27 ` tomas.vanek at fbl dot cz ` (9 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: tomas.vanek at fbl dot cz @ 2021-12-10 20:51 UTC (permalink / raw) To: gdb-prs https://sourceware.org/bugzilla/show_bug.cgi?id=28683 tomas.vanek at fbl dot cz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomas.vanek at fbl dot cz --- Comment #1 from tomas.vanek at fbl dot cz --- 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. -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/28683] advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M 2021-12-10 20:28 [Bug breakpoints/28683] New: advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M tomas.vanek at fbl dot cz 2021-12-10 20:51 ` [Bug breakpoints/28683] " tomas.vanek at fbl dot cz @ 2021-12-14 17:27 ` tomas.vanek at fbl dot cz 2022-10-13 9:21 ` luis.machado at arm dot com ` (8 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: tomas.vanek at fbl dot cz @ 2021-12-14 17:27 UTC (permalink / raw) To: gdb-prs https://sourceware.org/bugzilla/show_bug.cgi?id=28683 --- Comment #2 from tomas.vanek at fbl dot cz --- Created attachment 13855 --> https://sourceware.org/bugzilla/attachment.cgi?id=13855&action=edit until_break_command modified for Cortex-M SIGTRAMP_FRAME -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/28683] advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M 2021-12-10 20:28 [Bug breakpoints/28683] New: advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M tomas.vanek at fbl dot cz 2021-12-10 20:51 ` [Bug breakpoints/28683] " tomas.vanek at fbl dot cz 2021-12-14 17:27 ` tomas.vanek at fbl dot cz @ 2022-10-13 9:21 ` luis.machado at arm dot com 2022-10-14 11:26 ` tomas.vanek at fbl dot cz ` (7 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: luis.machado at arm dot com @ 2022-10-13 9:21 UTC (permalink / raw) To: gdb-prs https://sourceware.org/bugzilla/show_bug.cgi?id=28683 Luis Machado <luis.machado at arm dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |luis.machado at arm dot com --- Comment #3 from Luis Machado <luis.machado at arm dot com> --- Hi Tomas. Is this addressed by your other patch? -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/28683] advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M 2021-12-10 20:28 [Bug breakpoints/28683] New: advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M tomas.vanek at fbl dot cz ` (2 preceding siblings ...) 2022-10-13 9:21 ` luis.machado at arm dot com @ 2022-10-14 11:26 ` tomas.vanek at fbl dot cz 2022-10-14 15:02 ` tomas.vanek at fbl dot cz ` (6 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: tomas.vanek at fbl dot cz @ 2022-10-14 11:26 UTC (permalink / raw) To: gdb-prs https://sourceware.org/bugzilla/show_bug.cgi?id=28683 --- Comment #4 from tomas.vanek at fbl dot cz --- (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. -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/28683] advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M 2021-12-10 20:28 [Bug breakpoints/28683] New: advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M tomas.vanek at fbl dot cz ` (3 preceding siblings ...) 2022-10-14 11:26 ` tomas.vanek at fbl dot cz @ 2022-10-14 15:02 ` tomas.vanek at fbl dot cz 2022-10-16 15:28 ` tomas.vanek at fbl dot cz ` (5 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: tomas.vanek at fbl dot cz @ 2022-10-14 15:02 UTC (permalink / raw) To: gdb-prs https://sourceware.org/bugzilla/show_bug.cgi?id=28683 --- Comment #5 from tomas.vanek at fbl dot cz --- 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. -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/28683] advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M 2021-12-10 20:28 [Bug breakpoints/28683] New: advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M tomas.vanek at fbl dot cz ` (4 preceding siblings ...) 2022-10-14 15:02 ` tomas.vanek at fbl dot cz @ 2022-10-16 15:28 ` tomas.vanek at fbl dot cz 2022-10-17 7:14 ` luis.machado at arm dot com ` (4 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: tomas.vanek at fbl dot cz @ 2022-10-16 15:28 UTC (permalink / raw) To: gdb-prs https://sourceware.org/bugzilla/show_bug.cgi?id=28683 --- Comment #6 from tomas.vanek at fbl dot cz --- 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? -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/28683] advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M 2021-12-10 20:28 [Bug breakpoints/28683] New: advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M tomas.vanek at fbl dot cz ` (5 preceding siblings ...) 2022-10-16 15:28 ` tomas.vanek at fbl dot cz @ 2022-10-17 7:14 ` luis.machado at arm dot com 2022-10-21 10:02 ` luis.machado at arm dot com ` (3 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: luis.machado at arm dot com @ 2022-10-17 7:14 UTC (permalink / raw) To: gdb-prs https://sourceware.org/bugzilla/show_bug.cgi?id=28683 --- Comment #7 from Luis Machado <luis.machado at arm dot com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/28683] advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M 2021-12-10 20:28 [Bug breakpoints/28683] New: advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M tomas.vanek at fbl dot cz ` (6 preceding siblings ...) 2022-10-17 7:14 ` luis.machado at arm dot com @ 2022-10-21 10:02 ` luis.machado at arm dot com 2023-01-10 22:30 ` tomas.vanek at fbl dot cz ` (2 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: luis.machado at arm dot com @ 2022-10-21 10:02 UTC (permalink / raw) To: gdb-prs https://sourceware.org/bugzilla/show_bug.cgi?id=28683 Luis Machado <luis.machado at arm dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2022-10-21 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #8 from Luis Machado <luis.machado at arm dot com> --- Patch under review. -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/28683] advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M 2021-12-10 20:28 [Bug breakpoints/28683] New: advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M tomas.vanek at fbl dot cz ` (7 preceding siblings ...) 2022-10-21 10:02 ` luis.machado at arm dot com @ 2023-01-10 22:30 ` tomas.vanek at fbl dot cz 2023-01-10 22:32 ` tomas.vanek at fbl dot cz 2023-01-10 22:37 ` tomas.vanek at fbl dot cz 10 siblings, 0 replies; 12+ messages in thread From: tomas.vanek at fbl dot cz @ 2023-01-10 22:30 UTC (permalink / raw) To: gdb-prs https://sourceware.org/bugzilla/show_bug.cgi?id=28683 --- Comment #9 from tomas.vanek at fbl dot cz --- Created attachment 14571 --> https://sourceware.org/bugzilla/attachment.cgi?id=14571&action=edit testing code for STM32F4 or QEMU -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/28683] advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M 2021-12-10 20:28 [Bug breakpoints/28683] New: advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M tomas.vanek at fbl dot cz ` (8 preceding siblings ...) 2023-01-10 22:30 ` tomas.vanek at fbl dot cz @ 2023-01-10 22:32 ` tomas.vanek at fbl dot cz 2023-01-10 22:37 ` tomas.vanek at fbl dot cz 10 siblings, 0 replies; 12+ messages in thread From: tomas.vanek at fbl dot cz @ 2023-01-10 22:32 UTC (permalink / raw) To: gdb-prs https://sourceware.org/bugzilla/show_bug.cgi?id=28683 --- Comment #10 from tomas.vanek at fbl dot cz --- Created attachment 14572 --> https://sourceware.org/bugzilla/attachment.cgi?id=14572&action=edit testing image for STM32F4 or QEMU Use: qemu-system-arm -M netduinoplus2 -nographic -s -S -kernel tick_blink.elf -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/28683] advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M 2021-12-10 20:28 [Bug breakpoints/28683] New: advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M tomas.vanek at fbl dot cz ` (9 preceding siblings ...) 2023-01-10 22:32 ` tomas.vanek at fbl dot cz @ 2023-01-10 22:37 ` tomas.vanek at fbl dot cz 10 siblings, 0 replies; 12+ messages in thread From: tomas.vanek at fbl dot cz @ 2023-01-10 22:37 UTC (permalink / raw) To: gdb-prs https://sourceware.org/bugzilla/show_bug.cgi?id=28683 --- Comment #11 from tomas.vanek at fbl dot cz --- 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. -- You are receiving this mail because: You are on the CC list for the bug. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-01-10 22:37 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-12-10 20:28 [Bug breakpoints/28683] New: advance/until commands do not handle SIGTRAMP_FRAME on ARM Cortex-M tomas.vanek at fbl dot cz 2021-12-10 20:51 ` [Bug breakpoints/28683] " tomas.vanek at fbl dot cz 2021-12-14 17:27 ` tomas.vanek at fbl dot cz 2022-10-13 9:21 ` luis.machado at arm dot com 2022-10-14 11:26 ` tomas.vanek at fbl dot cz 2022-10-14 15:02 ` tomas.vanek at fbl dot cz 2022-10-16 15:28 ` tomas.vanek at fbl dot cz 2022-10-17 7:14 ` luis.machado at arm dot com 2022-10-21 10:02 ` luis.machado at arm dot com 2023-01-10 22:30 ` tomas.vanek at fbl dot cz 2023-01-10 22:32 ` tomas.vanek at fbl dot cz 2023-01-10 22:37 ` tomas.vanek at fbl dot cz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).