From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26447 invoked by alias); 1 Oct 2018 06:58:39 -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 26434 invoked by uid 89); 1 Oct 2018 06:58:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Commercial, Managing, Directors, 1012 X-HELO: mga04.intel.com Received: from mga04.intel.com (HELO mga04.intel.com) (192.55.52.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 01 Oct 2018 06:58:36 +0000 Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Sep 2018 23:58:34 -0700 Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by fmsmga006.fm.intel.com with ESMTP; 30 Sep 2018 23:58:33 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.213]) by IRSMSX154.ger.corp.intel.com ([169.254.12.130]) with mapi id 14.03.0319.002; Mon, 1 Oct 2018 07:58:33 +0100 From: "Metzger, Markus T" To: Pierre Marsais CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH] Add support for recording xsave x86 instruction Date: Mon, 01 Oct 2018 06:58:00 -0000 Message-ID: References: <20180921003827.1525-1-pierre.marsais@lse.epita.fr> <20181001002516.GA31390@trigger> In-Reply-To: <20181001002516.GA31390@trigger> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00002.txt.bz2 Hello Pierre, > On Thu, Sep 27, 2018 at 08:44:44AM +0000, Metzger, Markus T wrote: > >> + if (!__get_cpuid_count(0xd, i, &size, &offset, &tmp1, &tm= p2)) > >> + return -1; > > > > This would check the native configuration, correct? What if we > > recorded remotely on a different x86 box? >=20 > Oops, yes. I don't find how to query the offsets/sizes remotely, however = there is > XSTATE areas sizes in gdb/common/x86-xstate.h. I think we can assume that > those values are correct. OK. Other parts of GDB are using those, as well, rather than querying cpui= d. > > Also I think that we would need to check the inferior architecture to > > handle 32-bit compatibility mode. >=20 > I'm not sure to follow you. In which cases 32-bit behaves differently tha= n 64-bit ? Fewer registers. XSAVE is not writing the upper registers area. > >> + if (record_full_arch_list_add_mem (tmpu64 + offset, size)) > >> + return -1; > > > > Looks like this assumes the standard (non-compacted) XSAVE format. > > > > For the compacted format, the offset must be computed by accumulating > > the sizes of preceding components. >=20 > If I'm not mistaken, the compact format is only used by XSAVEC instructio= n, which > doesn't have the same opcode. The XSAVE instruction seems unrelated to th= is > format. You're right. It doesn't write the full header ,though. And there's a spe= cial case with XCR0[1]. > >> +if ![istarget "*86*-*linux*"] then { > >> + verbose "Skipping i386 reverse tests." > >> + return > >> +} > > > > Why exclude 64-bit? >=20 > Isn't this roughly the same as: > [ istarget "x86_64-*linux*" ] && [ istarget "i?86-*linux*" ] thus excludi= ng all arch > but 32 and 64 bit x86 ? I mistook it for i?86. Markus. 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