gdb+gdbserver/Linux: avoid reading registers while going through shell
authorPedro Alves <pedro@palves.net>
Mon, 27 Jun 2022 19:41:50 +0000 (20:41 +0100)
committerPedro Alves <pedro@palves.net>
Tue, 28 Jun 2022 17:11:29 +0000 (18:11 +0100)
commita9deee17d33235eeba401eebed55c85a742e3358
tree3dbd67fe9ee0566ceab74a4692c7abf42ce7fc60
parent9117c7b452ef76304f4394a97c887d0c4af439f5
gdb+gdbserver/Linux: avoid reading registers while going through shell

For every stop, Linux GDB and GDBserver save the stopped thread's PC,
in lwp->stop_pc.  This is done in save_stop_reason, in both
gdb/linux-nat.c and gdbserver/linux-low.cc.  However, while we're
going through the shell after "run", in startup_inferior, we shouldn't
be reading registers, as we haven't yet determined the target's
architecture -- the shell's architecture may not even be the same as
the final inferior's.

In gdb/linux-nat.c, lwp->stop_pc is only needed when the thread has
stopped for a breakpoint, and since when going through the shell, no
breakpoint is going to hit, we could simply teach save_stop_reason to
only record the stop pc when the thread stopped for a breakpoint.

However, in gdbserver/linux-low.cc, lwp->stop_pc is used in more cases
than breakpoint hits (e.g., it's used in tracepoints & the
"while-stepping" feature).

So to avoid GDB vs GDBserver divergence, we apply the same approach to
both implementations.

We set a flag in the inferior (process in GDBserver) whenever it is
being nursed through the shell, and when that flag is set,
save_stop_reason bails out early.  While going through the shell,
we'll only ever get process exits (normal or signalled), random
signals, and exec events, so nothing is lost.

Change-Id: If0f01831514d3a74d17efd102875de7d2c6401ad
gdb/fork-child.c
gdb/inferior.h
gdb/linux-nat.c
gdbserver/fork-child.cc
gdbserver/inferiors.h
gdbserver/linux-low.cc