Read stop_pc after updating the gdbarch when exec'ing
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.
This commit is contained in:
parent
fc80982757
commit
1bb7c05977
|
@ -1,3 +1,8 @@
|
|||
2017-09-05 Simon Marchi <simon.marchi@ericsson.com>
|
||||
|
||||
* infrun.c (handle_inferior_event_1): When exec'ing, read
|
||||
stop_pc after follow_exec.
|
||||
|
||||
2017-09-05 Simon Marchi <simon.marchi@ericsson.com>
|
||||
|
||||
* remote.c (process_g_packet): Update error message.
|
||||
|
|
|
@ -5309,8 +5309,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);
|
||||
|
||||
|
@ -5319,6 +5317,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). */
|
||||
|
|
Loading…
Reference in New Issue