public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Torsten@Robitzki.de
To: Luis Machado <luis.machado@linaro.org>
Cc: gdb@sourceware.org
Subject: Re: How to support interrupting a single step
Date: Fri, 27 Mar 2020 18:15:02 +0100	[thread overview]
Message-ID: <D5595B6A-522E-4F1D-A115-84EF8047914B@Robitzki.de> (raw)
In-Reply-To: <66219d95-9f03-7e83-7245-a9fecf670687@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 3146 bytes --]

Hi Luis,

I’m sorry, for the very late reply!

> Am 18.10.2019 um 15:08 schrieb Luis Machado <luis.machado@linaro.org>:
> 
> The behavior of GDB when dealing with a tight/endless loop is known. See https://sourceware.org/bugzilla/show_bug.cgi?id=21221.

that Bug describes behavior, that a tide loops can’t be jumped over. In my case, I try to interrupt that scenario. So running the binary, till that loop. Interrupt execution and finding the program counter in that loop. Then single stepping over the loop (either ’s’ or ’n’). Then gdb does not break on the next execution of the loop and I’m unable to break into the debugger again. ctrl-c simply does nothing and I have to kill the debug server, so that the lost connection to the debug server gives me the prompt back.

Debugging the packages send and received, I find following:

^C

00d0030020276f0200b86a0200008c0021d0030020000000000000000000000000000000000000000000000000
remote_pass_ctrlc called
remote_interrupt called
Sending packet: $s#73...Packet received: T05hwbreak;thread:0000DEAD;
Sending packet: $g#67...Packet received: aba50200010000007017000001000000000000000000000000000000d00300200000000000000000000000000000000000000000d0030020276f0200ba6a020000980021d0030020000000000000000000000000000000000000000000000000
Sending packet: $s#73...^Cremote_pass_ctrlc called
remote_interrupt called
Packet received: T05hwbreak;thread:0000DEAD;
Sending packet: $g#67...Packet received: aba50200010000007017000001000000000000000000000000000000d00300200000000000000000000000000000000000000000d0030020276f0200bc6a020000000021d0030020000000000000000000000000000000000000000000000000
Sending packet: $s#73...Packet received: T05hwbreak;thread:0000DEAD;
Sending packet: $g#67...Packet received: aba50200010000007017000001000000000000000000000000000000d00300200000000000000000000000000000000000000000d0030020276f0200be6a020000000021d0030020000000000000000000000000000000000000000000000000

I would expect that once GDB recognizes, that I want to interrupt execution, it would stop sending ’s’ and ‚g‘ packages.

> The problem of GDB sending lots of 's' and 'g' packets is also known, but i thought it had been fixed a while ago. We tried to harden that mechanism a bit more.
> 
> Are you running an older GDB version by any chance? If not, it may be a good idea to file a ticket so we can take a look at it.

$ arm-none-eabi-gdb -v
GNU gdb (GNU Tools for Arm Embedded Processors 8-2019-q3-update) 8.3.0.20190703-git
Copyright (C) 2019 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.

> It should already be interruptible, but the timing and speed of communications between GDB and the debug server tends to cause problems.

Wouldn’t it be enough, if GDB just stops to execute these ’s’, ‚g‘ package sequences? If not, what do I have to implement on the debug server side, to let my interrupt such a situation?

best regards,

Torsten

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-03-27 17:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-04 15:25 Torsten Robitzki
2019-10-18 13:08 ` Luis Machado
2020-03-27 17:15   ` Torsten [this message]
2020-03-27 18:27     ` Luis Machado
2020-03-30  9:15       ` Torsten
2020-03-30 10:56         ` Luis Machado

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=D5595B6A-522E-4F1D-A115-84EF8047914B@Robitzki.de \
    --to=torsten@robitzki.de \
    --cc=gdb@sourceware.org \
    --cc=luis.machado@linaro.org \
    /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).