[binutils-gdb] Change xstate_bv handling to use 8 bytes of data.

[sergiodj+buildbot at sergiodj dot net]

*** TEST RESULTS FOR COMMIT ff6527bb52e2938b53687a42d1bcda09300e9390 ***

Author: Michael Sturm <michael.sturm@intel.com>
Branch: master
Commit: ff6527bb52e2938b53687a42d1bcda09300e9390

Change xstate_bv handling to use 8 bytes of data.

The size of the state-component bitmap as specified in
Intel(R) 64 and IA-32 Architectures Software Developer's Manual,
Chapter 13.4.2 is 8 bytes.
So far, the data types used for xstate_bv_p (gdb_byte*),
clear_bv (unsigned int) and tdep->xcr0 (uint64_t) were
inconsistent. But, since the xstate components were still
fitting into a single byte, the code still worked
as expected.
However, with the addition of the PKU feature (bit 9),
using one byte for the bitmap will no longer be sufficient.

This patch changes related code to use 64 bit data types
consistently and changes read/write acces of the XSAVE
header in the xsave buffer to use the endianess-aware
functions extract_unsigned_integer and store_unsigned_integer.
This is required to make sure that eventual differences
in endianess between host and target are taken care off.

gdb/Changelog:
2016-04-18  Michael Sturm  <michael.sturm@intel.com>

     * i387-tdep.c (i387_supply_xsave): Change type
     of clear_bv to ULONGEST. Replace gdb_byte *xstate_bv_p
     with ULONGEST xstate_bv and use extract_unsigned_integer
     and store_unsigned_integer to read/write its value from
     the xsave buffer.
     (i387_collect_xsave): Replace gdb_byte *xstate_bv_p
     with ULONGEST initial_xstate_bv and use
     extract_unsigned_integer/store_unsigned_integer to
     read/write its value from the xsave buffer.
     Change type of clear_bv to ULONGEST.

gdbserver/Changelog:
2016-04-18  Michael Sturm  <michael.sturm@intel.com>

     * i387-fp.c (i387_cache_to_xsave): Change type of clear_bv to
     unsigned long long.
     (i387_fxsave_to_cache): Likewise.

Change-Id: I0de254158960b4f7bcbc9fe2fb857034fa1f7ca5
Signed-off-by: Michael Sturm <michael.sturm@intel.com>