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 5E0693858D33; Wed, 27 Sep 2023 12:39:49 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5E0693858D33
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1695818389;
	bh=sDNuIwGmDrgN4XImiug4yc0LuL70L4RVo2omgd6ZqOM=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=gO5ngBrxAJhFkX3hhQZoATYnLPFnEL7Mut5EWha7lOHcd1TZ39PQjapbJTEhCjo4I
	 DC93hdwgiB5v7Qepl72+DWtwnq6z/0B2Ltg5HQUc28Nhw35xpgTzDEV3o0EfHur56l
	 h2qrrOUiQJLvmcf/cDznbGwXWr+4oUNBIBiwfJwY=
From: "luis.machado at arm dot com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/30872] Assertion `buffer.copy_insn_closure.get () !=
 nullptr' failed
Date: Wed, 27 Sep 2023 12:39:49 +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: 13.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: luis.machado at arm dot com
X-Bugzilla-Status: ASSIGNED
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-30872-4717-D9XpGcjQiQ@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-30872-4717@http.sourceware.org/bugzilla/>
References: <bug-30872-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=3D30872

--- Comment #8 from Luis Machado <luis.machado at arm dot com> ---
Well, just should've been a bit obvious. I'm still checking this, but here's
some useful information.

The displaced stepping machinery in gdb, which is used to side-step breakpo=
ints
without removing them, uses scratch space for executing the instructions ou=
t of
their original location.

That scratch location was picked a while ago to be the entry point of the
program, from the auxv's AT_ENTRY value. That's usually the first instructi=
on
of _start.

Now, your example program starts from _start. So things get a bit confusing
because gdb is trying to execute and modify things using the same address.

As a temporary workaround, you can disable displaced stepping. It likely wo=
n't
make a difference for your case.

set displaced-stepping off

That should allow you to resume your debugging session.

I'll see what can be done about this corner case.

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