From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93911 invoked by alias); 5 Dec 2016 13:52:47 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 92020 invoked by uid 89); 5 Dec 2016 13:52:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=eventual, H*RU:HELO, Hx-spam-relays-external:HELO, ia32 X-HELO: mga09.intel.com Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 05 Dec 2016 13:52:36 +0000 Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP; 05 Dec 2016 05:52:34 -0800 X-ExtLoop1: 1 Received: from msturm-mobl2.ger.corp.intel.com (HELO [172.28.205.49]) ([172.28.205.49]) by fmsmga006.fm.intel.com with ESMTP; 05 Dec 2016 05:52:32 -0800 Subject: Re: [PATCH v2 2/5] Change xstate_bv handling to use 8 bytes of data. To: Luis Machado , mark.kettenis@xs4all.nl, palves@redhat.com, eliz@gnu.org References: <1480599538-30543-1-git-send-email-michael.sturm@intel.com> <1480599538-30543-3-git-send-email-michael.sturm@intel.com> <3d0e8b2b-441c-4329-9568-0aede49995cd@codesourcery.com> Cc: gdb-patches@sourceware.org From: "Sturm, Michael" Message-ID: <5845711F.3050808@intel.com> Date: Mon, 05 Dec 2016 13:52:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <3d0e8b2b-441c-4329-9568-0aede49995cd@codesourcery.com> Content-Type: text/plain; charset="windows-1252"; format="flowed" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2016-12/txt/msg00141.txt.bz2 Hi Luis, thanks for your feedback - please see my comments inline below. Thanks and Regards, Michael On 02/12/2016 02:26, Luis Machado wrote: > On 12/01/2016 07:38 AM, Michael Sturm wrote: >> 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. >> >> gdb/Changelog: >> 2016-04-18 Michael Sturm >> >> * 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. This is required to make sure that >> eventual differences in endianess between host and >> target are taken care off. >> (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. > > Too lengthy a description. It only needs to say what was done, not why. Ok, will be fixed in next revision. > >> >> gdbserver/Changelog: >> 2016-04-18 Michael Sturm >> >> * 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 >> --- >> gdb/gdbserver/i387-fp.c | 8 ++++---- >> gdb/i387-tdep.c | 33 +++++++++++++++++++++------------ >> 2 files changed, 25 insertions(+), 16 deletions(-) >> >> diff --git a/gdb/gdbserver/i387-fp.c b/gdb/gdbserver/i387-fp.c >> index a90729a..d0b0736 100644 >> --- a/gdb/gdbserver/i387-fp.c >> +++ b/gdb/gdbserver/i387-fp.c >> @@ -273,14 +273,14 @@ i387_cache_to_xsave (struct regcache *regcache,=20 >> void *buf) >> struct i387_xsave *fp =3D (struct i387_xsave *) buf; >> int i; >> unsigned long val, val2; >> - unsigned int clear_bv; >> unsigned long long xstate_bv =3D 0; >> + unsigned long long clear_bv =3D 0; >> char raw[64]; >> char *p; >> /* Amd64 has 16 xmm regs; I386 has 8 xmm regs. */ >> int num_xmm_registers =3D register_size (regcache->tdesc, 0) =3D=3D 8= ?=20 >> 16 : 8; >> >> - /* The supported bits in `xstat_bv' are 1 byte. Clear part in >> + /* The supported bits in `xstat_bv' are 8 bytes. Clear part in >> vector registers if its bit in xstat_bv is zero. */ > > Might as well fixup the "Clear part in" that sounds odd. Does it mean=20 > some specific bits need to be cleared? This part of the comment is there for a long time - I think the original=20 author wanted to make a connection between the bits in xstate_bv and the actual memory corresponding to the=20 respective register "part". What happens is that if the bit corresponding to X86_XSTATE_AVX is set in clear_bv, zero out=20 corresponding memory in the xstate buffer. > >> clear_bv =3D (~fp->xstate_bv) & x86_xcr0; >> >> @@ -643,12 +643,12 @@ i387_xsave_to_cache (struct regcache *regcache,=20 >> const void *buf) >> struct i387_fxsave *fxp =3D (struct i387_fxsave *) buf; >> int i, top; >> unsigned long val; >> - unsigned int clear_bv; >> + unsigned long long clear_bv; >> gdb_byte *p; >> /* Amd64 has 16 xmm regs; I386 has 8 xmm regs. */ >> int num_xmm_registers =3D register_size (regcache->tdesc, 0) =3D=3D 8= ?=20 >> 16 : 8; >> >> - /* The supported bits in `xstat_bv' are 1 byte. Clear part in >> + /* The supported bits in `xstat_bv' are 8 bytes. Clear part in > > Same here. Please see above. > >> vector registers if its bit in xstat_bv is zero. */ >> clear_bv =3D (~fp->xstate_bv) & x86_xcr0; >> >> diff --git a/gdb/i387-tdep.c b/gdb/i387-tdep.c >> index f7a3b55..ef3a631 100644 >> --- a/gdb/i387-tdep.c >> +++ b/gdb/i387-tdep.c >> @@ -898,7 +898,7 @@ i387_supply_xsave (struct regcache *regcache, int=20 >> regnum, >> struct gdbarch_tdep *tdep =3D gdbarch_tdep (gdbarch); >> const gdb_byte *regs =3D (const gdb_byte *) xsave; >> int i; >> - unsigned int clear_bv; >> + ULONGEST clear_bv; > > Is there a reason you're using ULONGEST here and unsigned long long=20 > above? We should make those uses consistent. Well, above we're in GDBserver, where unsigned long long is the type=20 used in the rest of the file. Here, we're in GDB, were ULONGEST seems to be the preferred type. I wanted to be consistent with what is=20 used in the respective files so far. > >> static const gdb_byte zero[MAX_REGISTER_SIZE] =3D { 0 }; >> enum >> { >> @@ -950,12 +950,15 @@ i387_supply_xsave (struct regcache *regcache,=20 >> int regnum, >> >> if (regclass !=3D none) >> { >> - /* Get `xstat_bv'. */ >> - const gdb_byte *xstate_bv_p =3D XSAVE_XSTATE_BV_ADDR (regs); >> + /* Get `xstat_bv'. The supported bits in `xstat_bv' are 8=20 >> bytes. */ > > Two spaces after periods. Will be fixed in the next revision. > >> + enum bfd_endian byte_order =3D gdbarch_byte_order (gdbarch); >> + ULONGEST xstate_bv =3D 0; >> >> - /* The supported bits in `xstat_bv' are 1 byte. Clear part in >> - vector registers if its bit in xstat_bv is zero. */ >> - clear_bv =3D (~(*xstate_bv_p)) & tdep->xcr0; >> + xstate_bv =3D extract_unsigned_integer (XSAVE_XSTATE_BV_ADDR=20 >> (regs), >> + 8, byte_order); >> + >> + /* Clear part in vector registers if its bit in xstat_bv is=20 >> zero. */ > > See comment above about "Clear part in" Please see above. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928