binutils-gdb/gdbserver/win32-low.h
Andrew Burgess 1048062a3f gdbserver: pass osabi to GDB in more target descriptions
Problem Description
-------------------

On a Windows machine I built gdbserver, configured for the target
'x86_64-w64-mingw32', then on a GNU/Linux machine I built GDB with
support for all target (--enable-targets=all).

On the Windows machine I start gdbserver with a small test binary:

  $ gdbserver 192.168.129.25:54321 C:\some\directory\executable.exe

On the GNU/Linux machine I start GDB without the test binary, and
connect to gdbserver.

As I have not given GDB the test binary, my expectation is that GDB
would connect to gdbserver and then download the file over the remote
protocol, but instead I was presented with this message:

  (gdb) target remote 192.168.129.25:54321
  Remote debugging using 192.168.129.25:54321
  warning: C:\some\directory\executable.exe: No such file or directory.
  0x00007ffa3e1e1741 in ?? ()
  (gdb)

What I found is that if I told GDB where to find the binary, like
this:

  (gdb) file target:C:/some/directory/executable.exe
  A program is being debugged already.
  Are you sure you want to change the file? (y or n) y
  Reading C:/some/directory/executable.exe from remote target...
  warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
  Reading C:/some/directory/executable.exe from remote target...
  Reading symbols from target:C:/some/directory/executable.exe...
  (gdb)

then GDB would download the executable.

The Actual Issue
----------------

I tracked the problem down to exec_file_find (solib.c).  The remote
target was passing an absolute Windows filename (beginning with "C:/"
in this case), but in exec_file_find GDB was failing the
IS_TARGET_ABSOLUTE_PATH call, and so was treating the filename as
relative.

The IS_TARGET_ABSOLUTE_PATH call was failing because GDB thought that
the file system kind was "unix", and as the filename didn't start with
a "/" it assumed the filename was not absolute.

But I'm connecting to a Windows target and 'target-file-system-kind'
was set to "auto", so GDB should be figuring out that the target
file-system is "dos-based".

Looking in effective_target_file_system_kind (filesystem.c), we find
that the logic of "auto" is delegated to the current gdbarch.  However
in windows-tdep.c we see:

  set_gdbarch_has_dos_based_file_system (gdbarch, 1);

So if we are using a Windows gdbarch we should have "dos-based"
filesystems.  What this means is that after connecting to the remote
target GDB has selected the wrong gdbarch.

What's happening is that the target description sent back by the
remote target only includes the x86-64 registers.  There's no
information about which OS we're on.  As a consequence, GDB picks the
first x86-64 gdbarch which can handle the provided register set, which
happens to be a GNU/Linux gdbarch.

And indeed, there doesn't appear to be anywhere in gdbserver that sets
the osabi on the target descriptions. Some target descriptions do have
their osabi set when the description is created, e.g. in:

  gdb/arch/amd64.c	- Sets GNU/Linux osabi when appropriate.
  gdb/arch/i386.c	- Likewise.
  gdb/arch/tic6x.c	- Always set GNU/Linux osabi.

There are also some cases in gdb/features/*.c where the tdesc is set,
but these locations are only called from GDB, not from gdbserver.

This means that many target descriptions are created without an osabi,
gdbserver does nothing to fix this, and the description is returned to
GDB without an osabi included.  This leaves GDB having to guess what
the target osabi is, and in some cases, GDB can get this wrong.

Proposed Solution
-----------------

I propose to change init_target_desc so that it requires an gdb_osabi
to be passed in, this will then be used to set the target_desc osabi
field.

I believe that within gdbserver init_target_desc is called for every
target_desc, so this should mean that every target_desc has an
opportunity to set the osabi to something sane.

I did consider passing the osabi into the code which creates the
target_desc objects, but that would require updating far more code, as
each target has its own code for creating target descriptions.
The approach taken here requires minimal changes and forces every
user of init_target_desc to think about what the correct osabi is.

In some cases, e.g. amd64, where the osabi is already set when the
target_desc is created, the init_target_desc call will override the
current value, however, we should always be replacing it with the same
actual value.  i.e. if the target_desc is created with the osabi set
to GNU/Linux, then this should only happen when gdbserver is built for
GNU/Linux, in which case the init_target_desc should also be setting
the osabi to GNU/Linux.

The Tricky Bits
---------------

Some targets, like amd64, use a features based approach for creating
target_desc objects, there's a function in arch/amd64.c which creates
a target_desc, adds features too it, and returns the new target_desc.
This target_desc is then passed to an init_target_desc call within
gdbserver.  This is the easy case to handle.

Then there are other targets which instead have a fixed set of xml
files, each of which is converted into a .dat file, which is then used
to generate a .cc file, which is compiled into gdbserver.  The
generated .cc file creates the target_desc object and calls
init_target_desc on it.  In this case though the target description
that is sent to GDB isn't generated from the target_desc object, but
is instead the contents of the fixed xml file.  For this case the
osabi which we pass to init_target_desc should match the osabi that
exists in the fixed xml file.

Luckily, in the previous commit I copied the osabi information from
the fixed xml files into the .dat files.  So in this commit I have
extended regdat.sh to read the osabi from the .dat file and use it in
the generated init_target_desc call.

The problem with some of these .dat base targets is that their fixed
xml files don't currently contain any osabi information, and the file
names don't indicate that they are Linux only (despite them currently
only being used from gdbserver for Linux targets), so I don't
currently feel confident adding any osabi information to these files.
An example would be features/rs6000/powerpc-64.xml.  For now I've just
ignored these cases.  The init_target_desc will use GDB_OSABI_UNKNOWN
which is the default.  This means that for these targets nothing
changes from the current behaviour.  But many other targets do now
pass the osabi back.  Targets that do pass the osabi back are
improved with this commit.

Conclusion
----------

Now when I connect to the Windows remote the target description
returned includes the osabi name.  With this extra information GDB
selects the correct gdbarch object, which means that GDB understands
the target has a "dos-based" file-system.  With that correct GDB
understands that the filename it was given is absolute, and so fetches
the file from the remote as we'd like.

Reviewed-By: Kevin Buettner <kevinb@redhat.com>
2024-11-12 12:51:36 +00:00

222 lines
6.8 KiB
C++

/* Internal interfaces for the Win32 specific target code for gdbserver.
Copyright (C) 2007-2024 Free Software Foundation, Inc.
This file is part of GDB.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
#ifndef GDBSERVER_WIN32_LOW_H
#define GDBSERVER_WIN32_LOW_H
#include <windows.h>
#include "nat/windows-nat.h"
#include "gdbsupport/osabi.h"
struct target_desc;
/* The inferior's target description. This is a global because the
Windows ports support neither bi-arch nor multi-process. */
extern const struct target_desc *win32_tdesc;
#ifdef __x86_64__
extern const struct target_desc *wow64_win32_tdesc;
#endif
#ifdef __CYGWIN__
constexpr enum gdb_osabi WINDOWS_OSABI = GDB_OSABI_CYGWIN;
#else
constexpr enum gdb_osabi WINDOWS_OSABI = GDB_OSABI_WINDOWS;
#endif
struct win32_target_ops
{
/* Architecture-specific setup. */
void (*arch_setup) (void);
/* The number of target registers. */
int (*num_regs) (void);
/* Perform initializations on startup. */
void (*initial_stuff) (void);
/* Fetch the context from the inferior. */
void (*get_thread_context) (windows_nat::windows_thread_info *th);
/* Called just before resuming the thread. */
void (*prepare_to_resume) (windows_nat::windows_thread_info *th);
/* Called when a thread was added. */
void (*thread_added) (windows_nat::windows_thread_info *th);
/* Fetch register from gdbserver regcache data. */
void (*fetch_inferior_register) (struct regcache *regcache,
windows_nat::windows_thread_info *th,
int r);
/* Store a new register value into the thread context of TH. */
void (*store_inferior_register) (struct regcache *regcache,
windows_nat::windows_thread_info *th,
int r);
void (*single_step) (windows_nat::windows_thread_info *th);
const unsigned char *breakpoint;
int breakpoint_len;
/* Amount by which to decrement the PC after a breakpoint is
hit. */
int decr_pc_after_break;
/* Get the PC register from REGCACHE. */
CORE_ADDR (*get_pc) (struct regcache *regcache);
/* Set the PC register in REGCACHE. */
void (*set_pc) (struct regcache *regcache, CORE_ADDR newpc);
/* Breakpoint/Watchpoint related functions. See target.h for comments. */
int (*supports_z_point_type) (char z_type);
int (*insert_point) (enum raw_bkpt_type type, CORE_ADDR addr,
int size, struct raw_breakpoint *bp);
int (*remove_point) (enum raw_bkpt_type type, CORE_ADDR addr,
int size, struct raw_breakpoint *bp);
int (*stopped_by_watchpoint) (void);
CORE_ADDR (*stopped_data_address) (void);
};
extern struct win32_target_ops the_low_target;
/* Target ops definitions for a Win32 target. */
class win32_process_target : public process_stratum_target
{
public:
int create_inferior (const char *program,
const std::vector<char *> &program_args) override;
int attach (unsigned long pid) override;
int kill (process_info *proc) override;
int detach (process_info *proc) override;
void mourn (process_info *proc) override;
void join (int pid) override;
bool thread_alive (ptid_t pid) override;
void resume (thread_resume *resume_info, size_t n) override;
ptid_t wait (ptid_t ptid, target_waitstatus *status,
target_wait_flags options) override;
void fetch_registers (regcache *regcache, int regno) override;
void store_registers (regcache *regcache, int regno) override;
int read_memory (CORE_ADDR memaddr, unsigned char *myaddr,
int len) override;
int write_memory (CORE_ADDR memaddr, const unsigned char *myaddr,
int len) override;
void request_interrupt () override;
bool supports_z_point_type (char z_type) override;
int insert_point (enum raw_bkpt_type type, CORE_ADDR addr,
int size, raw_breakpoint *bp) override;
int remove_point (enum raw_bkpt_type type, CORE_ADDR addr,
int size, raw_breakpoint *bp) override;
bool supports_hardware_single_step () override;
bool stopped_by_watchpoint () override;
CORE_ADDR stopped_data_address () override;
bool supports_qxfer_siginfo () override;
int qxfer_siginfo (const char *annex, unsigned char *readbuf,
unsigned const char *writebuf,
CORE_ADDR offset, int len) override;
bool supports_get_tib_address () override;
int get_tib_address (ptid_t ptid, CORE_ADDR *addr) override;
const gdb_byte *sw_breakpoint_from_kind (int kind, int *size) override;
CORE_ADDR read_pc (regcache *regcache) override;
void write_pc (regcache *regcache, CORE_ADDR pc) override;
bool stopped_by_sw_breakpoint () override;
bool supports_stopped_by_sw_breakpoint () override;
const char *thread_name (ptid_t thread) override;
bool supports_pid_to_exec_file () override
{ return true; }
const char *pid_to_exec_file (int pid) override;
bool supports_disable_randomization () override
{
return windows_nat::disable_randomization_available ();
}
};
struct gdbserver_windows_process : public windows_nat::windows_process_info
{
windows_nat::windows_thread_info *thread_rec
(ptid_t ptid,
windows_nat::thread_disposition_type disposition) override;
int handle_output_debug_string (struct target_waitstatus *ourstatus) override;
void handle_load_dll (const char *dll_name, LPVOID base) override;
void handle_unload_dll () override;
bool handle_access_violation (const EXCEPTION_RECORD *rec) override;
int attaching = 0;
/* A status that hasn't been reported to the core yet, and so
win32_wait should return it next, instead of fetching the next
debug event off the win32 API. */
struct target_waitstatus cached_status;
/* Non zero if an interrupt request is to be satisfied by suspending
all threads. */
int soft_interrupt_requested = 0;
/* Non zero if the inferior is stopped in a simulated breakpoint done
by suspending all the threads. */
int faked_breakpoint = 0;
/* True if current_process_handle needs to be closed. */
bool open_process_used = false;
/* Zero during the child initialization phase, and nonzero
otherwise. */
int child_initialization_done = 0;
};
/* The sole Windows process. */
extern gdbserver_windows_process windows_process;
/* Retrieve the context for this thread, if not already retrieved. */
extern void win32_require_context (windows_nat::windows_thread_info *th);
#endif /* GDBSERVER_WIN32_LOW_H */