From: Simon Marchi <simon.marchi@ericsson.com>
To: <gdb-patches@sourceware.org>
Cc: Simon Marchi <simon.marchi@ericsson.com>
Subject: [PATCH 2/4] Read stop_pc after updating the gdbarch when exec'ing
Date: Sun, 27 Aug 2017 10:16:00 -0000 [thread overview]
Message-ID: <1503828934-26404-3-git-send-email-simon.marchi@ericsson.com> (raw)
In-Reply-To: <1503828934-26404-1-git-send-email-simon.marchi@ericsson.com>
When an inferior execs and changes architecture (e.g. 64 bits to 32
bits), the gdbarch associated to the inferior is updated by the
follow_exec call in handle_inferior_event_1. We should avoid doing any
register read before that point, because the registers sent by the
remote side will be those of the new architecture, but we would
interpret them using the old architecture. We do just that by setting
stop_pc during this window, which obviously requires reading the
registers. This results in gdb.multi/multi-arch-exec.exp failing, GDB
outputting the following error:
Truncated register 50 in remote 'g' packet
This patch fixes that by postponing the setting of stop_pc to after
we've updated the inferior gdbarch.
This bug was hiding another problem, and as such introduces some
failures in gdb.base/foll-exec-mode.exp. The following patch takes care
of that.
gdb/ChangeLog:
* infrun.c (handle_inferior_event_1): When exec'ing, read
stop_pc after follow_exec.
---
gdb/infrun.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gdb/infrun.c b/gdb/infrun.c
index d0e4105..de0605f 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -5318,8 +5318,6 @@ Cannot fill $_exitsignal with the correct signal number.\n"));
if (!ptid_equal (ecs->ptid, inferior_ptid))
context_switch (ecs->ptid);
- stop_pc = regcache_read_pc (get_thread_regcache (ecs->ptid));
-
/* Do whatever is necessary to the parent branch of the vfork. */
handle_vfork_child_exec_or_exit (1);
@@ -5328,6 +5326,8 @@ Cannot fill $_exitsignal with the correct signal number.\n"));
stop. */
follow_exec (inferior_ptid, ecs->ws.value.execd_pathname);
+ stop_pc = regcache_read_pc (get_thread_regcache (ecs->ptid));
+
/* In follow_exec we may have deleted the original thread and
created a new one. Make sure that the event thread is the
execd thread for that case (this is a nop otherwise). */
--
2.7.4
next prev parent reply other threads:[~2017-08-27 10:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-18 11:10 Check for truncated registers in process_g_packet Lionel Flandrin
2016-10-18 15:50 ` Simon Marchi
2016-10-18 16:07 ` Lionel Flandrin
2016-10-27 15:23 ` Lionel Flandrin
2016-11-08 10:37 ` Pedro Alves
2017-08-25 10:53 ` Yao Qi
2017-08-25 21:05 ` Simon Marchi
2017-08-25 22:55 ` Simon Marchi
2017-08-27 10:16 ` [PATCH 0/4] Try to fix the gdb.multi/multi-arch-exec.exp failure Simon Marchi
2017-08-27 10:16 ` Simon Marchi [this message]
2017-09-05 10:12 ` [PATCH 2/4] Read stop_pc after updating the gdbarch when exec'ing Yao Qi
2017-08-27 10:16 ` [PATCH 4/4] Test different follow-exec-mode settings in gdb.multi/multi-arch-exec.exp Simon Marchi
2017-09-05 10:40 ` Yao Qi
2017-09-05 15:40 ` Simon Marchi
2017-08-27 10:16 ` [PATCH 1/4] Improve "'g' reply is is to long" error message Simon Marchi
2017-09-05 9:49 ` Yao Qi
2017-08-27 10:16 ` [PATCH 3/4] Add thread after updating gdbarch when exec'ing Simon Marchi
2017-09-05 10:37 ` Yao Qi
2017-09-05 15:30 ` Simon Marchi
2017-09-05 15:44 ` Simon Marchi
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=1503828934-26404-3-git-send-email-simon.marchi@ericsson.com \
--to=simon.marchi@ericsson.com \
--cc=gdb-patches@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