From: Andrew Burgess <andrew.burgess@embecosm.com>
To: gdb-patches@sourceware.org
Cc: jimw@sifive.com, palmer@sifive.com, jhb@FreeBSD.org,
Andrew Burgess <andrew.burgess@embecosm.com>
Subject: [PATCH 1/2] gdb/riscv: Stop prologue scan if instruction fetch/decode fails
Date: Mon, 05 Nov 2018 23:10:00 -0000 [thread overview]
Message-ID: <1ab6341c3c73c6e0b501e7b25d6d64744d7cdbc0.1541459121.git.andrew.burgess@embecosm.com> (raw)
In-Reply-To: <cover.1541459121.git.andrew.burgess@embecosm.com>
In-Reply-To: <cover.1541459121.git.andrew.burgess@embecosm.com>
If an error is thrown from the instruction fetch/decode during a
prologue scan then we should stop the prologue scan at that point
rather than propagating the error.
Propagating the error out of the prologue scan was causing unwanted
behaviour when connecting to a remote target. When connecting to a
remote target GDB will read the $pc value from the target and try to
establish a frame-id, this can involve a prologue scan.
If the target has not yet had a program loaded into it, and the $pc
value is pointing an unreadable memory, then the prologue scan would
throw an error, this would then cause GDB to abandon its attempt to
connect to the target. It was in fact impossible to connect to the
target at all.
With this patch in place GDB simply stops the prologue scan at the
point of the error, and GDB can now successfully connect.
I did consider placing the error catch within riscv_insn::decode
however, in the end I felt that catching and ignoring errors should be
done on a case by case basis, the other users of riscv_insn::decode
are currently all related to finding the next pc as part of software
single step. If the user asks for a step and the contents of $pc
can't be read then if feels like terminating that command with an
error is the right thing to do.
gdb/ChangeLog:
* riscv-tdep.c (riscv_insn::decode): Update header comment.
(riscv_scan_prologue): Catch errors thrown from
riscv_insn::decode and stop prologue scan.
---
gdb/ChangeLog | 6 ++++++
gdb/riscv-tdep.c | 27 ++++++++++++++++++++++++---
2 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/gdb/riscv-tdep.c b/gdb/riscv-tdep.c
index db372e21632..aae93ea2fac 100644
--- a/gdb/riscv-tdep.c
+++ b/gdb/riscv-tdep.c
@@ -1256,7 +1256,9 @@ riscv_insn::fetch_instruction (struct gdbarch *gdbarch,
return extract_unsigned_integer (buf, instlen, byte_order);
}
-/* Fetch from target memory an instruction at PC and decode it. */
+/* Fetch from target memory an instruction at PC and decode it. This can
+ throw an error if the memory access fails, callers are responsible for
+ handling this error if that is appropriate. */
void
riscv_insn::decode (struct gdbarch *gdbarch, CORE_ADDR pc)
@@ -1427,10 +1429,29 @@ riscv_scan_prologue (struct gdbarch *gdbarch,
for (next_pc = cur_pc = start_pc; cur_pc < end_pc; cur_pc = next_pc)
{
struct riscv_insn insn;
+ bool decode_valid = false;
/* Decode the current instruction, and decide where the next
- instruction lives based on the size of this instruction. */
- insn.decode (gdbarch, cur_pc);
+ instruction lives based on the size of this instruction. If the
+ decode (which includes fetching from memory) fails then we stop
+ the prologue scan at this point. */
+ TRY
+ {
+ insn.decode (gdbarch, cur_pc);
+ decode_valid = true;
+ }
+ CATCH (ex, RETURN_MASK_ERROR)
+ {
+ /* Ignore errors. */
+ }
+ END_CATCH
+
+ if (!decode_valid)
+ {
+ end_prologue_addr = cur_pc;
+ break;
+ }
+
gdb_assert (insn.length () > 0);
next_pc = cur_pc + insn.length ();
--
2.14.5
next prev parent reply other threads:[~2018-11-05 23:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-05 23:10 [PATCH 0/2] RISC-V Prologue Scan And Test Improvement Andrew Burgess
2018-11-05 23:10 ` [PATCH 2/2] gdb/riscv: Update test to support targets without FP hardware Andrew Burgess
2018-11-05 23:10 ` Andrew Burgess [this message]
2018-11-05 23:37 ` [PATCH 1/2] gdb/riscv: Stop prologue scan if instruction fetch/decode fails Jim Wilson
2018-11-06 11:18 ` Andrew Burgess
2018-11-06 19:40 ` Jim Wilson
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=1ab6341c3c73c6e0b501e7b25d6d64744d7cdbc0.1541459121.git.andrew.burgess@embecosm.com \
--to=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=jhb@FreeBSD.org \
--cc=jimw@sifive.com \
--cc=palmer@sifive.com \
/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