Merge ~liushuyu-011/ubuntu/+source/gdb:ubuntu/jammy-devel into ubuntu/+source/gdb:ubuntu/jammy-devel

Proposed by Zixing Liu
Status: Merged
Merged at revision: 44ef798f8602769ff04b76861c225bb349ec5182
Proposed branch: ~liushuyu-011/ubuntu/+source/gdb:ubuntu/jammy-devel
Merge into: ubuntu/+source/gdb:ubuntu/jammy-devel
Diff against target: 333 lines (+285/-2)
6 files modified
debian/changelog (+7/-0)
debian/control (+2/-1)
debian/ (+2/-1)
debian/patches/Make-sure-a-copy_insn_closure-is-available-when-we-h.patch (+103/-0)
debian/patches/Only-allow-closure-lookup-by-address-if-there-are-th.patch (+167/-0)
debian/patches/series (+4/-0)
Reviewer Review Type Date Requested Status
Sergio Durigan Junior (community) Approve
git-ubuntu import Pending
Review via email:

Description of the change

This merge proposal backports several patches from GDB 13 to fix an issue on armhf where GDB will break the program executed due to incorrectly placed debug instructions in the process memory.

You can find the full details on this issue here:

To post a comment you must log in.
Revision history for this message
Sergio Durigan Junior (sergiodj) wrote :

Thanks for the MP, Zixing.

I've left some minor requests below. Overall the changes LGTM, but having a PPA where I could find the package with the fix ready to be test would have helped. Either way, I'm building it now and reserving an ARM64 machine to perform the test before sponsoring the upload.

The SRU text is also OK. I'll let you know for sure after I perform the tests.

Meanwhile, you can work on addressing the comments below. Thanks.

review: Needs Fixing
Revision history for this message
Zixing Liu (liushuyu-011) wrote :

Hi Sergio,

I do have a PPA build for this: Launchpad was having issues yesterday, so I did not post the links. Sorry for the inconvenience.

Revision history for this message
Zixing Liu (liushuyu-011) wrote :

Done. Comments addressed.

Revision history for this message
Sergio Durigan Junior (sergiodj) wrote :

Ah, thanks Zinxing. I see that the build has failed on all architectures but armhf. Could you retrigger those just to make sure that they're OK, please?

I'm still struggling to obtain access to an arm64 machine where I can test these changes. I might go ahead and upload it, though, because my previous experience with machine reservation on the internal MAAS is not great.

Revision history for this message
Sergio Durigan Junior (sergiodj) wrote :

Uploaded, thanks:

$ dput gdb_12.1-0ubuntu1~22.04.1_source.changes
Trying to upload package to ubuntu
Checking signature on .changes
gpg: /home/sergio/work/gdb/gdb_12.1-0ubuntu1~22.04.1_source.changes: Valid signature from 106DA1C8C3CBBF14
Checking signature on .dsc
gpg: /home/sergio/work/gdb/gdb_12.1-0ubuntu1~22.04.1.dsc: Valid signature from 106DA1C8C3CBBF14
Uploading to ubuntu (via ftp to
  Uploading gdb_12.1-0ubuntu1~22.04.1.dsc: done.
  Uploading gdb_12.1-0ubuntu1~22.04.1.debian.tar.xz: done.
  Uploading gdb_12.1-0ubuntu1~22.04.1_source.buildinfo: done.
  Uploading gdb_12.1-0ubuntu1~22.04.1_source.changes: done.
Successfully uploaded packages.

review: Approve
Revision history for this message
Zixing Liu (liushuyu-011) wrote (last edit ):

> Could you retrigger those just to make sure that they're OK, please?

Retrying. Launchpad has been under stress for the past few days, so it may take a few tries.

Revision history for this message
Sergio Durigan Junior (sergiodj) wrote :

On Friday, October 27 2023, Zixing Liu wrote:

>> Could you retrigger those just to make sure that they're OK, please?
> Retrying. Launchpad has been under stress in the pass few days, so it may take a few tries.


GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1diff --git a/debian/changelog b/debian/changelog
2index 366bc0f..ce4d5a2 100644
3--- a/debian/changelog
4+++ b/debian/changelog
5@@ -1,3 +1,10 @@
6+gdb (12.1-0ubuntu1~22.04.1) jammy; urgency=medium
8+ * SRU: LP: #2041396: Fix SIGILL generated by GDB 12.1 on armhf by
9+ backporting the fix from GDB 13.1 to 22.04 LTS.
11+ -- Zixing Liu <> Thu, 26 Oct 2023 12:04:57 -0600
13 gdb (12.1-0ubuntu1~22.04) jammy-proposed; urgency=medium
15 * SRU: LP: #1971474: Update to the final 12.1 release in 22.04 LTS.
16diff --git a/debian/control b/debian/control
17index fc692a2..283d41b 100644
18--- a/debian/control
19+++ b/debian/control
20@@ -1,5 +1,6 @@
21 Source: gdb
22-Maintainer: Héctor Orón Martínez <>
23+Maintainer: Ubuntu Developers <>
24+XSBC-Original-Maintainer: Héctor Orón Martínez <>
25 Uploaders: Riku Voipio <>,
26 Sergio Durigan Junior <>
27 Section: devel
28diff --git a/debian/ b/debian/
29index de505b6..1f6032a 100644
30--- a/debian/
31+++ b/debian/
32@@ -1,5 +1,6 @@
33 Source: gdb
34-Maintainer: Héctor Orón Martínez <>
35+Maintainer: Ubuntu Developers <>
36+XSBC-Original-Maintainer: Héctor Orón Martínez <>
37 Uploaders: Riku Voipio <>,
38 Sergio Durigan Junior <>
39 Section: devel
40diff --git a/debian/patches/Make-sure-a-copy_insn_closure-is-available-when-we-h.patch b/debian/patches/Make-sure-a-copy_insn_closure-is-available-when-we-h.patch
41new file mode 100644
42index 0000000..95bf1fd
43--- /dev/null
44+++ b/debian/patches/Make-sure-a-copy_insn_closure-is-available-when-we-h.patch
45@@ -0,0 +1,103 @@
46+From da6edc2feb66d75b89f65834d8bccad45c47525c Mon Sep 17 00:00:00 2001
47+From: Luis Machado <>
48+Date: Tue, 25 Oct 2022 11:01:32 +0100
49+Subject: [PATCH 1/2] Make sure a copy_insn_closure is available when we have a
50+ match in copy_insn_closure_by_addr
52+PR gdb/29272
54+Investigating PR29272, it was mentioned a particular test used to work on
55+GDB 10, but it started failing with GDB 11 onwards. I tracked it down to
56+some displaced stepping improvements on commit
59+In particular, one of the corner cases using copy_insn_closure_by_addr got
60+silently broken. It is hard to spot because it doesn't have any good tests
61+for it, and the situation is quite specific to the Arm target.
63+Essentially, the change from the displaced stepping improvements made it so
64+we could still invoke copy_insn_closure_by_addr correctly to return the
65+pointer to a copy_insn_closure, but it always returned nullptr due to
66+the order of the statements in displaced_step_buffer::prepare.
68+The way it is now, we first write the address of the displaced step buffer
69+to PC and then save the copy_insn_closure pointer.
71+The problem is that writing to PC for the Arm target requires figuring
72+out if the new PC is thumb mode or not.
74+With no copy_insn_closure data, the logic to determine the thumb mode
75+during displaced stepping doesn't work, and gives random results that
76+are difficult to track (SIGILL, SIGSEGV etc).
78+Fix this by reordering the PC write in displaced_step_buffer::prepare
79+and, for safety, add an assertion to
80+displaced_step_buffer::copy_insn_closure_by_addr so GDB stops right
81+when it sees this invalid situation. If this gets broken again in the
82+future, it will be easier to spot.
85+Approved-By: Simon Marchi <>
86+Origin: upstream
87+Applied-Upstream: 13.1,;a=commit;h=1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679
88+Last-Update: 2023-10-26
90+ gdb/displaced-stepping.c | 28 +++++++++++++++++++++++++---
91+ 1 file changed, 25 insertions(+), 3 deletions(-)
93+diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c
94+index e2afbe42f58..d73a875afbb 100644
95+--- a/gdb/displaced-stepping.c
96++++ b/gdb/displaced-stepping.c
97+@@ -139,15 +139,33 @@ displaced_step_buffers::prepare (thread_info *thread, CORE_ADDR &displaced_pc)
99+ }
101+- /* Resume execution at the copy. */
102+- regcache_write_pc (regcache, buffer->addr);
104+ /* This marks the buffer as being in use. */
105+ buffer->current_thread = thread;
107+ /* Save this, now that we know everything went fine. */
108+ buffer->copy_insn_closure = std::move (copy_insn_closure);
110++ /* Reset the displaced step buffer state if we failed to write PC.
111++ Otherwise we will prevent this buffer from being used, as it will
112++ always have a thread in buffer->current_thread. */
113++ auto reset_buffer = make_scope_exit
114++ ([buffer] ()
115++ {
116++ buffer->current_thread = nullptr;
117++ buffer->copy_insn_closure.reset ();
118++ });
120++ /* Adjust the PC so it points to the displaced step buffer address that will
121++ be used. This needs to be done after we save the copy_insn_closure, as
122++ some architectures (Arm, for one) need that information so they can adjust
123++ other data as needed. In particular, Arm needs to know if the instruction
124++ being executed in the displaced step buffer is thumb or not. Without that
125++ information, things will be very wrong in a random way. */
126++ regcache_write_pc (regcache, buffer->addr);
128++ /* PC update successful. Discard the displaced step state rollback. */
129++ reset_buffer.release ();
131+ /* Tell infrun not to try preparing a displaced step again for this inferior if
132+ all buffers are taken. */
133+ thread->inf->displaced_step_state.unavailable = true;
134+@@ -264,7 +282,11 @@ displaced_step_buffers::copy_insn_closure_by_addr (CORE_ADDR addr)
135+ for (const displaced_step_buffer &buffer : m_buffers)
136+ {
137+ if (addr == buffer.addr)
138++ {
139++ /* The closure information should always be available. */
140++ gdb_assert (buffer.copy_insn_closure.get () != nullptr);
141+ return buffer.copy_insn_closure.get ();
142++ }
143+ }
145+ return nullptr;
149diff --git a/debian/patches/Only-allow-closure-lookup-by-address-if-there-are-th.patch b/debian/patches/Only-allow-closure-lookup-by-address-if-there-are-th.patch
150new file mode 100644
151index 0000000..dabba97
152--- /dev/null
153+++ b/debian/patches/Only-allow-closure-lookup-by-address-if-there-are-th.patch
154@@ -0,0 +1,167 @@
155+From a9734f5e1640f47a089a472ca9c3b7e0df5c77ee Mon Sep 17 00:00:00 2001
156+From: Luis Machado <>
157+Date: Thu, 28 Sep 2023 11:08:29 +0100
158+Subject: [PATCH 2/2] Only allow closure lookup by address if there are threads
159+ displaced-stepping
161+Since commit 1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, we have an assertion in
162+displaced_step_buffers::copy_insn_closure_by_addr that makes sure a closure
163+is available whenever we have a match between the provided address argument and
164+the buffer address.
166+That is fine, but the report in PR30872 shows this assertion triggering when
167+it really shouldn't. After some investigation, here's what I found out.
169+The 32-bit Arm architecture is the only one that calls
170+gdbarch_displaced_step_copy_insn_closure_by_addr directly, and that's because
171+32-bit Arm needs to figure out the thumb state of the original instruction
172+that we displaced-stepped through the displaced-step buffer.
174+Before the assertion was put in place by commit
175+1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, there was the possibility of
176+getting nullptr back, which meant we were not doing a displaced-stepping
179+Now, with the assertion in place, this is running into issues.
181+It looks like displaced_step_buffers::copy_insn_closure_by_addr is
182+being used to return a couple different answers depending on the
183+state we're in:
185+1 - If we are actively displaced-stepping, then copy_insn_closure_by_addr
186+is supposed to return a valid closure for us, so we can determine the
187+thumb mode.
189+2 - If we are not actively displaced-stepping, then copy_insn_closure_by_addr
190+should return nullptr to signal that there isn't any displaced-step buffers
191+in use, because we don't have a valid closure (but we should always have
194+Since the displaced-step buffers are always allocated, but not always used,
195+that means the buffers will always contain data. In particular, the buffer
196+addr field cannot be used to determine if the buffer is active or not.
198+For instance, we cannot set the buffer addr field to 0x0, as that can be a
199+valid PC in some cases.
201+My understanding is that the current_thread field should be a good candidate
202+to signal that a particular displaced-step buffer is active or not. If it is
203+nullptr, we have no threads using that buffer to displaced-step. Otherwise,
204+it is an active buffer in use by a particular thread.
206+The following fix modifies the displaced_step_buffers::copy_insn_closure_by_addr
207+function so we only attempt to return a closure if the buffer has an assigned
208+current_thread and if the buffer address matches the address argument.
210+Alternatively, I think we could use a function to answer the question of
211+whether we're actively displaced-stepping (so we have an active buffer) or
214+I've also added a testcase that exercises the problem. It should reproduce
215+reliably on Arm, as that is the only architecture that faces this problem
216+at the moment.
218+Regression-tested on Ubuntu 20.04. OK?
221+Approved-By: Simon Marchi <>
222+Origin: upstream
223+Applied-Upstream: 13.1,;a=commit;h=5d4a870e05ac45e3f5a301c672a4079995b5db7a
224+Last-Update: 2023-10-26
226+ gdb/displaced-stepping.c | 3 +-
227+ .../gdb.base/displaced-step-closure.c | 21 ++++++++++
228+ .../gdb.base/displaced-step-closure.exp | 39 +++++++++++++++++++
229+ 3 files changed, 62 insertions(+), 1 deletion(-)
230+ create mode 100644 gdb/testsuite/gdb.base/displaced-step-closure.c
231+ create mode 100644 gdb/testsuite/gdb.base/displaced-step-closure.exp
233+diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c
234+index d73a875afbb..006c3913098 100644
235+--- a/gdb/displaced-stepping.c
236++++ b/gdb/displaced-stepping.c
237+@@ -281,7 +281,8 @@ displaced_step_buffers::copy_insn_closure_by_addr (CORE_ADDR addr)
238+ {
239+ for (const displaced_step_buffer &buffer : m_buffers)
240+ {
241+- if (addr == buffer.addr)
242++ /* Make sure we have active buffers to compare to. */
243++ if (buffer.current_thread != nullptr && addr == buffer.addr)
244+ {
245+ /* The closure information should always be available. */
246+ gdb_assert (buffer.copy_insn_closure.get () != nullptr);
247+diff --git a/gdb/testsuite/gdb.base/displaced-step-closure.c b/gdb/testsuite/gdb.base/displaced-step-closure.c
248+new file mode 100644
249+index 00000000000..8540538e915
250+--- /dev/null
251++++ b/gdb/testsuite/gdb.base/displaced-step-closure.c
252+@@ -0,0 +1,21 @@
253++/* This testcase is part of GDB, the GNU debugger.
255++ Copyright 2023 Free Software Foundation, Inc.
257++ This program is free software; you can redistribute it and/or modify
258++ it under the terms of the GNU General Public License as published by
259++ the Free Software Foundation; either version 3 of the License, or
260++ (at your option) any later version.
262++ This program is distributed in the hope that it will be useful,
263++ but WITHOUT ANY WARRANTY; without even the implied warranty of
265++ GNU General Public License for more details.
267++ You should have received a copy of the GNU General Public License
268++ along with this program. If not, see <>. */
270++int main (int argc, char **argv)
272++ return 0;
274+diff --git a/gdb/testsuite/gdb.base/displaced-step-closure.exp b/gdb/testsuite/gdb.base/displaced-step-closure.exp
275+new file mode 100644
276+index 00000000000..3389cd4f0de
277+--- /dev/null
278++++ b/gdb/testsuite/gdb.base/displaced-step-closure.exp
279+@@ -0,0 +1,39 @@
280++# Copyright 2023 Free Software Foundation, Inc.
282++# This program is free software; you can redistribute it and/or modify
283++# it under the terms of the GNU General Public License as published by
284++# the Free Software Foundation; either version 3 of the License, or
285++# (at your option) any later version.
287++# This program is distributed in the hope that it will be useful,
288++# but WITHOUT ANY WARRANTY; without even the implied warranty of
290++# GNU General Public License for more details.
292++# You should have received a copy of the GNU General Public License
293++# along with this program. If not, see <>.
295++# This file is part of the gdb testsuite.
297++# Test a displaced stepping closure management bug, where a closure lookup
298++# by address returns a match even if no displaced stepping is currently
299++# taking place.
302++if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile}] } {
303++ return -1
306++if ![runto_main] {
307++ return -1
310++# We have a breakpoint at the current pc (from stopping at main). Step over
311++# the breakpoint.
312++gdb_test "stepi" ".*" "step-over breakpoint"
314++# Now attempt to disassemble the entry point function, where the displaced
315++# stepping buffer is. With the bug, gdb will crash when we attempt to list
316++# the PC that was used to displaced-step the previous instruction.
317++gdb_test "disassemble _start" ".*End of assembler dump\." \
318++ "disassemble through displaced-step buffer"
322diff --git a/debian/patches/series b/debian/patches/series
323index e4521f4..8ef04e2 100644
324--- a/debian/patches/series
325+++ b/debian/patches/series
326@@ -14,3 +14,7 @@ fork-inferior-fix
327 # Ubuntu/Linaro
328 gdb-strings.patch
329 ptrace-error-verbosity.patch
331+# Backported from GDB 13.1


People subscribed via source and target branches