public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Adrian Oltean <adrian.oltean@nxp.com>
To: John Baldwin <jhb@FreeBSD.org>,
	"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: Context switch during stepping causes weird behavior
Date: Wed, 5 Oct 2022 06:48:44 +0000	[thread overview]
Message-ID: <AM6PR04MB4630EB6889EAB1AA00D67A85F15D9@AM6PR04MB4630.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <c24fd310-b92f-9d69-5859-34006458787b@FreeBSD.org>

Hi John,

Thanks for sharing your experience. I'm also planning to recommend our customers to use breakpoints instead of actual step operations. However, I still don't like the uncontrollable GDB when stepping and kernel thread gets moved. In your case, I see a friendlier behavior - at least stepping stops at some point, even though not reaching the expected code section. This would be my goal as well. Maybe someone can suggest how to patch the GDB code in order to suspend the step when GDB detects that stepping thread is actually changed. Unfortunately, I don't have much knowledge about the GDB code and all my attempts failed so far.

Thank you,
Adrian

-----Original Message-----

Interrupts make single-stepping on bare-metal or OS kernels hard.  When doing similar things for debugging FreeBSD's kernel via bare-metal stubs (e.g. in QEMU or in FreeBSD's hypervisor) I generally use 'until' and/or breakpoints instead to work around this rather than using normal stepping.

On the GDB server side (for the GDB stub in FreeBSD's hypervisor) I've thought about doing odd things like trying to defer interrupts while stepping but there isn't a really good way to deal with that in general.

(Most of the time when trying to step what happens for me is that I get a reported stop back for a PC in the timer interrupt handler for the local APIC timer interrupt, and then GDB sees that the PC is "out of range" and just stops at that point)

--
John Baldwin

  reply	other threads:[~2022-10-05  6:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-04 12:19 Adrian Oltean
2022-10-04 16:57 ` John Baldwin
2022-10-05  6:48   ` Adrian Oltean [this message]
2022-10-05 16:53     ` John Baldwin
2022-10-07 15:40       ` Keith Seitz
2022-10-12  6:46         ` [EXT] " Adrian Oltean
2022-10-13  6:34           ` Luis Machado
2022-10-13  6:41             ` Adrian Oltean
2022-10-10  9:52 ` Luis Machado
2022-10-12  6:40   ` [EXT] " Adrian Oltean

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=AM6PR04MB4630EB6889EAB1AA00D67A85F15D9@AM6PR04MB4630.eurprd04.prod.outlook.com \
    --to=adrian.oltean@nxp.com \
    --cc=gdb@sourceware.org \
    --cc=jhb@FreeBSD.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).