Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pierre Marsais <pierre.marsais@lse.epita.fr>
To: "Metzger, Markus T" <markus.t.metzger@intel.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Add support for recording xsave x86 instruction
Date: Mon, 01 Oct 2018 00:25:00 -0000	[thread overview]
Message-ID: <20181001002516.GA31390@trigger> (raw)
In-Reply-To: <A78C989F6D9628469189715575E55B236B35E55E@IRSMSX104.ger.corp.intel.com>

Hi,

Thanks for the review.

On Thu, Sep 27, 2018 at 08:44:44AM +0000, Metzger, Markus T wrote:
>> +            if (!__get_cpuid_count(0xd, i, &size, &offset, &tmp1, &tmp2))
>> +              return -1;
>
> This would check the native configuration, correct?  What if we recorded
> remotely on a different x86 box?

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.

> Also I think that we would need to check the inferior architecture to handle
> 32-bit compatibility mode.

I'm not sure to follow you. In which cases 32-bit behaves differently
than 64-bit ?

>> +
>> +            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.

If I'm not mistaken, the compact format is only used by XSAVEC
instruction, which doesn't have the same opcode. The XSAVE instruction
seems unrelated to this format.

>> +if ![istarget "*86*-*linux*"] then {
>> +    verbose "Skipping i386 reverse tests."
>> +    return
>> +}
>
> Why exclude 64-bit?

Isn't this roughly the same as:
[ istarget "x86_64-*linux*" ] && [ istarget "i?86-*linux*" ]
thus excluding all arch but 32 and 64 bit x86 ?

Anyways it seems to be working on my x86_64 linux with
$ make check TESTS=gdb.reverse/i386-xsave-reverse.exp

Regards,

-- 
Pierre "Pimzero" MARSAIS,
EPITA 2018; GISTRE | ACU | LSE


  reply	other threads:[~2018-10-01  0:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-21  0:38 Pierre Marsais
2018-09-27  8:45 ` Metzger, Markus T
2018-10-01  0:25   ` Pierre Marsais [this message]
2018-10-01  6:58     ` Metzger, Markus T
2018-10-03  0:05       ` Pierre Marsais
2018-10-01  0:29 ` [PATCH v2] " Pierre Marsais
2018-10-02 23:55 ` [PATCH v3] " Pierre Marsais
     [not found]   ` <CAMe9rOqTeGBckegskZLKxJJL-aexTiorLTEbL2kps_KjJs20Rg@mail.gmail.com>
2018-10-06  0:20     ` Pierre Marsais
2018-10-06  0:16 ` [PATCH v4 1/3] " Pierre Marsais
2018-10-06  0:16   ` [PATCH v4 3/3] Add support for recording xsavec " Pierre Marsais
2018-10-06  0:16   ` [PATCH v4 2/3] Do not mistreat instructions as cmpxchg8b Pierre Marsais
2018-10-11 11:56     ` Metzger, Markus T

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181001002516.GA31390@trigger \
    --to=pierre.marsais@lse.epita.fr \
    --cc=gdb-patches@sourceware.org \
    --cc=markus.t.metzger@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox