public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/29272] regression: previously OK rust tests crash with SIGILL/SEGV/ABRT on Debian armhf
Date: Fri, 11 Nov 2022 12:47:47 +0000 [thread overview]
Message-ID: <bug-29272-4717-DEaPNeDSi6@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-29272-4717@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=29272
--- Comment #7 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Luis Machado <luisgpm@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679
commit 1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679
Author: Luis Machado <luis.machado@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@efficios.com>
--
You are receiving this mail because:
You are on the CC list for the bug.
next prev parent reply other threads:[~2022-11-11 12:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-21 9:42 [Bug rust/29272] New: " infinity0 at pwned dot gg
2022-06-21 9:56 ` [Bug rust/29272] " infinity0 at pwned dot gg
2022-06-23 11:02 ` infinity0 at pwned dot gg
2022-06-23 11:10 ` infinity0 at pwned dot gg
2022-10-21 10:54 ` luis.machado at arm dot com
2022-10-21 10:54 ` luis.machado at arm dot com
2022-10-25 13:03 ` luis.machado at arm dot com
2022-10-31 10:16 ` luis.machado at arm dot com
2022-11-11 9:27 ` [Bug gdb/29272] " luis.machado at arm dot com
2022-11-11 12:47 ` cvs-commit at gcc dot gnu.org [this message]
2022-11-11 12:48 ` luis.machado at arm dot com
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=bug-29272-4717-DEaPNeDSi6@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=gdb-prs@sourceware.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).