public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Tomas Vanek <vanekt@fbl.cz>, gdb-patches@sourceware.org
Subject: Re: [PATCH v2] gdb: Modify until_break_command to act correctly on SIGTRAMP_FRAME
Date: Tue, 10 Jan 2023 10:31:44 -0500	[thread overview]
Message-ID: <f0f8828a-2a46-aa94-e42c-985d06b7732b@simark.ca> (raw)
In-Reply-To: <1666353538-15846-1-git-send-email-vanekt@fbl.cz>



On 10/21/22 07:58, Tomas Vanek wrote:
> This patch partially depends on
> gdb/arm: Terminate frame unwinding in M-profile lockup state
> (without it lockup state is unwound as if it were a normal
> stack frame).
> 
> The commands 'advance' and 'until' try to set a breakpoint
> on the bogus return address derived from Arm M-profile magic
> address (actually EXC_RETURN or a PC value indicating lockup).
> 
> The offending breakpoint should be set at the return address in
> the caller. 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 (EXC_RETURN) and GDB tries to set a breakpoint at
> 0xfffffff0. It should use a return value stacked by the exception
> instead.
> 
> Testbench setup:
> 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.
> 
> Steps to reproduce the problem:
> 
> 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
> 
> This patch adds skipping over frames that are not suitable for
> guarding with a breakpoint inspired by 'finish' command.
> If no suitable frame is found, a momentary breakpoint is not set.
> 
> v2: Comment fixes, bug reference.
> 
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28683
> Signed-off-by: Tomas Vanek <vanekt@fbl.cz>

Hi Tomas,

In order to better understand if this is the right fix, can you describe
what the different frames are in this situation, starting with the
current frame?  I'd like to see what the frame ids and frame types are.

Is there any chance this could be reproduced using the GDB simulator (or maybe
qemu), so I could tinker with it?

Simon

  parent reply	other threads:[~2023-01-10 15:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-21 11:58 Tomas Vanek
2022-10-21 11:58 ` Tomas Vanek
2022-10-27 10:31 ` Luis Machado
2022-10-27 17:46   ` Tomas Vanek
2022-11-22  6:48     ` Tomas Vanek
2022-11-22  7:27       ` Luis Machado
2022-11-28 11:48 ` [PING] " Tomas Vanek
2022-12-08  1:15   ` Luis Machado
2022-12-21  8:52     ` [PING 2] " Tomas Vanek
2023-01-10 13:19     ` [PING 3] " Tomas Vanek
2023-01-10 15:31 ` Simon Marchi [this message]
2023-01-10 16:33   ` Tomas Vanek
2023-01-10 17:48 ` Simon Marchi
2023-01-10 23:22   ` Tomas Vanek
2023-01-11  1:38     ` Simon Marchi
2023-02-02  6:38       ` Tomas Vanek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f0f8828a-2a46-aa94-e42c-985d06b7732b@simark.ca \
    --to=simark@simark.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=vanekt@fbl.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).