From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id EFE2D3858413; Sun, 31 Dec 2023 20:02:28 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EFE2D3858413
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1704052948;
	bh=Nan1wjJUHp4NR8Znq70woh8Mm7PkrRkupg1xv0ZQB8A=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=fc9ZVC8e4H+VSLWlQ4hwrrE81vv3l+8cDZKKXGd5DpzG60tl0gvBIpNjhPCF6qwwA
	 CWSD1c1J4T1TBZ6vGnOFarb72SlgDBtJ4FzysgAk7ghUGMpHW1LqlhYBR8QTC3zD0W
	 f4meStalVTWJJRmLIO37BCz9/uWjNLBjbT3esjFY=
From: "tromey at sourceware dot org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/31194] Stepping on "int3" instruction fails assertion.
Date: Sun, 31 Dec 2023 20:02:27 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: gdb
X-Bugzilla-Version: HEAD
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tromey at sourceware dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-31194-4717-BXLUoiIJyt@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-31194-4717@http.sourceware.org/bugzilla/>
References: <bug-31194-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gdb-prs.sourceware.org>

https://sourceware.org/bugzilla/show_bug.cgi?id=3D31194

--- Comment #9 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Peter0x44 from comment #7)
> > I'm not really sure how int3 is supposed to be handled
> Perhaps it would be beneficial to state what my preferences would be.

Yes, thanks.

I dug into the code a bit and, first of all, gdb already does
support this situation.  It's called a "permanent breakpoint"
in the implementation.

There's even a test for this, gdb.arch/i386-bp_permanent.exp.
However, that tests "continue", not stepping.

I think perhaps the issue is that we reach the end of handle_signal_stop
with:

(top-gdb) p random_signal
$30 =3D 0

and in particular maybe:

  /* If not, perhaps stepping/nexting can.  */
  if (random_signal)
    random_signal =3D !(ecs->event_thread->stop_signal () =3D=3D GDB_SIGNAL=
_TRAP
                      && currently_stepping (ecs->event_thread));

here the call to currently_stepping returns true.

Maybe this should be checking the PC and setting random_signal if it
is out of range?
Or maybe the earlier code that calls gdbarch_program_breakpoint_here_p
should set some sort of local flag, so that this can check it?

I don't really know infrun all that well and so I'm not sure how this
is intended to work.  I wonder if there are other scenarios to be
concerned with.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=