x86_64-windows GDB crash due to fs_base/gs_base registers

GDB is currently crashing anytime we try to access the fs_base/gs_base
registers, either to read them, or to write them. This can be observed
under various scenarios:
  - Explicit reference to those registers (eg: print $fs_base) --
    probably relatively rare;
  - Calling a function in the inferior, with the crash happening
    because we are trying to read those registers in order to save
    their value ahead of making the function call;
  - Just a plain "info registers";

The crash was introduced by the following commit:

    | commit 48aeef91c248291dd03583798904612426b1f40a
    | Date:   Mon Jun 26 18:14:43 2017 -0700
    | Subject: Include the fs_base and gs_base registers in amd64 target descriptions.

The Windows-nat implementation was unfortunately not prepared to deal
with those new registers. In particular, the way it fetches registers
is done by using a table where the index is the register number, and
the value at that index is the offset in the area in the thread's CONTEXT
data where the corresponding register value is stored.

For instance, in amd64-windows-nat.c, we can find the mappings static
array containing the following 57 elements in it:

    #define context_offset(x) (offsetof (CONTEXT, x))
    static const int mappings[] =
    {
      context_offset (Rax),
      [...]
      context_offset (FloatSave.MxCsr)
    };

That array is then used by windows_fetch_one_register via:

    char *context_offset = ((char *) &th->context) + mappings[r];

The problem is that fs_base's register number is 172, which is
well past the end of the mappings array (57 elements in total).
We end up getting an undefined offset, which happens to be so large
that it then causes the address where we try to read the register
value (a little bit later) to be invalid, thus crashing GDB with
a SEGV.

This patch side-steps the issue entirely by removing support for
those registers in GDB on x86_64-windows, because a look at the
CONTEXT structure indicates no support for getting those registers.

A more comprehensive fix would patch the potential buffer overflow
of the mappings array, but this can be done as a separate commit.

gdb/ChangeLog:

        * gdb/amd64-tdep.h (amd64_create_target_description): Add
        "segments" parameter.
        * gdb/amd64-tdep.c (amd64_none_init_abi, amd64_x32_none_init_abi)
        (_initialize_amd64_tdep): Update call to
        amd64_create_target_description.
        (amd64_target_description): Add "segments" parameter.  Adjust
        the implementation to use it.
        * gdb/amd64-linux-tdep.c (amd64_linux_read_description): Update
        call to amd64_create_target_description.
        * gdb/amd64-windows-tdep.c (amd64_windows_init_abi): Likewise.
        * gdb/arch/amd64.h (amd64_create_target_description): Add
        "segments" register.
        * gdb/arch/amd64.c (amd64_create_target_description): Add
        "segments" parameter.  Call create_feature_i386_64bit_segments
        only if SEGMENTS is true.
        * gdb/gdbserver/win32-i386-low.c (i386_arch_setup): Update
        call to amd64_create_target_description.

Tested on x86_64-windows using AdaCore's testsuite (by Joel Brobecker
<brobecker at adacore dot com>).

1 files changed, 2 insertions, 1 deletions

diff --git a/gdb/amd64-tdep.h b/gdb/amd64-tdep.h
index 7d3791ad936..94e012632ff 100644
--- a/gdb/amd64-tdep.h
+++ b/gdb/amd64-tdep.h
@@ -106,7 +106,8 @@ extern void amd64_init_abi (struct gdbarch_info info,
 extern void amd64_x32_init_abi (struct gdbarch_info info,
 				struct gdbarch *gdbarch,
 				const target_desc *default_tdesc);
-extern const struct target_desc *amd64_target_description (uint64_t xcr0);
+extern const struct target_desc *amd64_target_description (uint64_t xcr0,
+							   bool segments);
 
 /* Fill register REGNUM in REGCACHE with the appropriate
    floating-point or SSE register value from *FXSAVE.  If REGNUM is