[Bug 2041396] Re: gdb 12.1 generates SIGILL on armhf
Bug Watch Updater
2041396 at bugs.launchpad.net
Thu Oct 26 19:57:40 UTC 2023
Launchpad has imported 9 comments from the remote bug at
https://sourceware.org/bugzilla/show_bug.cgi?id=29272.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2022-06-21T09:42:13+00:00 Ximin Luo wrote:
Created attachment 14158
rustc debuginfo test sample #1
1. Compile the attached test file `rustc -g associated-types.rs`.
2. Run `gdb -x dbg.script ./associated-types`, dbg.script as follows:
~~~~
set charset UTF-8
show version
add-auto-load-safe-path /home/infinity0/rustc/./src/etc
set print pretty off
directory /home/infinity0/rustc/./src/etc
file /home/infinity0/rustc/build/armv7-unknown-linux-gnueabihf/test/debuginfo/associated-types.gdb/a
set language rust
break 'associated-types.rs':111
break 'associated-types.rs':118
break 'associated-types.rs':122
break 'associated-types.rs':130
break 'associated-types.rs':137
break 'associated-types.rs':140
run
print arg
continue
print inferred
print explicitly
continue
print arg
continue
print arg
continue
print a
print b
continue
print a
print b
continue
quit
~~~~
This works for all rustc versions (I was able to test 1.13 - 1.59) on
gdb 10 but fails with SIGILL on gdb 11.2 armhf Debian.
Other rustc debuginfo tests fail with other signals, SIGSEGV, SIGABRT,
etc. More specific details here: https://github.com/rust-
lang/rust/issues/96983
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2041396/comments/0
------------------------------------------------------------------------
On 2022-06-21T09:56:02+00:00 Ximin Luo wrote:
Whoops, I copied a dbg.script with local paths. Just delete those lines
and make sure you have the source file associated-types.rs in the
current directory, the reproduction still works. You also need to give
`RUSTC_BOOTSTRAP=` when compiling `rustc -g` as the file uses some
unstable features only meant for testing the rustc compiler.
~~~~
set charset UTF-8
show version
set print pretty off
set language rust
break 'associated-types.rs':111
break 'associated-types.rs':118
break 'associated-types.rs':122
break 'associated-types.rs':130
break 'associated-types.rs':137
break 'associated-types.rs':140
run
print arg
continue
print inferred
print explicitly
continue
print arg
continue
print arg
continue
print a
print b
continue
print a
print b
continue
quit
~~~~
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2041396/comments/1
------------------------------------------------------------------------
On 2022-06-23T11:02:08+00:00 Ximin Luo wrote:
> `RUSTC_BOOTSTRAP=`
Whoops, this should be `RUSTC_BOOTSTRAP=1`.
Same issue still exists with gdb 12.1 on Debian armhf.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2041396/comments/2
------------------------------------------------------------------------
On 2022-06-23T11:10:39+00:00 Ximin Luo wrote:
Switching off ASLR with `setarch -R` and forcing single-threaded mode
with `taskset -c 0` has no effect on the bug.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2041396/comments/3
------------------------------------------------------------------------
On 2022-10-21T10:54:28+00:00 Luis Machado wrote:
Sorry for the delayed reply.
I managed to reproduce this on Ubuntu 22.04 with rustc 1.58.1, but I get
a SIGSEGV. On Ubuntu 20.04, with rustc 1.57, I get a SIGILL. The gdb's
are the same, top-of-trunk.
This is an issue with displaced stepping in the Arm port of GDB. If you
disable it (set displaced-stepping off), the test runs fine.
I'll investigate this.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2041396/comments/4
------------------------------------------------------------------------
On 2022-10-25T13:03:05+00:00 Luis Machado wrote:
I have a WIP fix. Should hopefully be able to put it on the ML soon.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2041396/comments/5
------------------------------------------------------------------------
On 2022-10-31T10:16:26+00:00 Luis Machado wrote:
Tentative patch: https://sourceware.org/pipermail/gdb-
patches/2022-October/193162.html
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2041396/comments/6
------------------------------------------------------------------------
On 2022-11-11T12:47:47+00:00 Cvs-commit wrote:
The master branch has been updated by Luis Machado
<luisgpm at sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=binutils-
gdb.git;h=1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679
commit 1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679
Author: Luis Machado <luis.machado at arm.com>
Date: Tue Oct 25 11:01:32 2022 +0100
Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr
PR gdb/29272
Investigating PR29272, it was mentioned a particular test used to work on
GDB 10, but it started failing with GDB 11 onwards. I tracked it down to
some displaced stepping improvements on commit
187b041e2514827b9d86190ed2471c4c7a352874.
In particular, one of the corner cases using copy_insn_closure_by_addr got
silently broken. It is hard to spot because it doesn't have any good tests
for it, and the situation is quite specific to the Arm target.
Essentially, the change from the displaced stepping improvements made it so
we could still invoke copy_insn_closure_by_addr correctly to return the
pointer to a copy_insn_closure, but it always returned nullptr due to
the order of the statements in displaced_step_buffer::prepare.
The way it is now, we first write the address of the displaced step buffer
to PC and then save the copy_insn_closure pointer.
The problem is that writing to PC for the Arm target requires figuring
out if the new PC is thumb mode or not.
With no copy_insn_closure data, the logic to determine the thumb mode
during displaced stepping doesn't work, and gives random results that
are difficult to track (SIGILL, SIGSEGV etc).
Fix this by reordering the PC write in displaced_step_buffer::prepare
and, for safety, add an assertion to
displaced_step_buffer::copy_insn_closure_by_addr so GDB stops right
when it sees this invalid situation. If this gets broken again in the
future, it will be easier to spot.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29272
Approved-By: Simon Marchi <simon.marchi at efficios.com>
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2041396/comments/7
------------------------------------------------------------------------
On 2022-11-11T12:48:40+00:00 Luis Machado wrote:
Fixed. Please reopen if you see any issues.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2041396/comments/8
** Changed in: gdb
Status: Unknown => Fix Released
** Changed in: gdb
Importance: Unknown => Medium
** Bug watch added: github.com/rust-lang/rust/issues #96983
https://github.com/rust-lang/rust/issues/96983
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/2041396
Title:
gdb 12.1 generates SIGILL on armhf
Status in gdb:
Fix Released
Status in gdb package in Ubuntu:
New
Bug description:
[ Impact ]
* GDB 12.1 introduced a regression where it will break program execution when the program contains mixed ARM code and THUMB code.
* Upstream stated they tested the changes on Ubuntu 20.04 and it went okay.
[ Test Plan ]
Considering the following C program:
```
__attribute__((target("arm"), noinline))
int thumb_func() {
return 42;
}
__attribute__((target("thumb")))
int main() { return thumb_func(); }
```
If you build it using `gcc repro.c -ggdb3 -Og -o repro` and run the
GDB using the following commands ...
```
b 3
r
c
```
(you can save the contents above to a file and run GDB using `gdb -x
script ./repro`)
... you will notice GDB broke the program and threw SIGILL.
If you run the program without GDB, the program exits normally.
[ Where problems could occur ]
* GDB is a complex software. As the patch suggests, it may break other use cases (like single-stepping) entirely.
* Since this is an ARM-only patch, it's unlikely to affect other CPU architectures. However, it is possible that this fix may break ARM64 execution.
[ Other Info ]
* This bug has been fixed in GDB 13, but the fix was never backported to GDB 12. You can find the upstream bug in the remote bug watch.
To manage notifications about this bug go to:
https://bugs.launchpad.net/gdb/+bug/2041396/+subscriptions
More information about the foundations-bugs
mailing list