gdb/x86: move have_ptrace_getfpxregs global into gdb/nat directory

The have_ptrace_getfpxregs global tracks whether GDB or gdbserver is
running on a kernel that supports the GETFPXREGS ptrace request.

Currently this global is declared twice (once in GDB and once in
gdbserver), I think it makes sense to move this global into the nat/
directory, and have a single declaration and definition.

While moving this variable I have converted it to a tribool, as that
was what it really was, if even used the same numbering as the tribool
enum (-1, 0, 1).  Where have_ptrace_getfpxregs was used I have updated
in the obvious way.

However, while making this change I noticed what I think is a bug in
x86_linux_nat_target::read_description and x86_linux_read_description,
both of these functions can be called multiple times, but in both
cases we only end up calling i386_linux_read_description the first
time through in the event that PTRACE_GETFPXREGS is not supported.
This is because initially have_ptrace_getfpxregs will be
TRIBOOL_UNKNOWN, but after the ptrace call fails we set
have_ptrace_getfpxregs to TRIBOOL_FALSE.  The next time we attempt to
read the target description we'll skip the ptrace call, and so skip
the call to i386_linux_read_description.

I've not tried to address this preexisting bug in this commit, this is
purely a refactor, there should be no user visible changes after this
commit.  In later commits I'll merge the gdbserver and GDB code
together into the nat/ directory, and after that I'll try to address
this bug.

Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
This commit is contained in:
Andrew Burgess
2024-04-26 14:24:40 +01:00
parent 3d5394c501
commit 18d4886c00
8 changed files with 62 additions and 46 deletions

View File

@@ -109,6 +109,7 @@ case "${gdbserver_host}" in
srv_tgtobj="${srv_tgtobj} nat/linux-btrace.o"
srv_tgtobj="${srv_tgtobj} nat/x86-linux.o"
srv_tgtobj="${srv_tgtobj} nat/x86-linux-dregs.o"
srv_tgtobj="${srv_tgtobj} nat/i386-linux.o"
srv_linux_usrregs=yes
srv_linux_regsets=yes
srv_linux_thread_db=yes