RE: [PATCH 0/7] Intel(R) MPX registers support.

["Tedeschi, Walfred" <walfred dot tedeschi at intel dot com>]

Hello Mark,

First of all thanks for your quick response!

I am not sure if I understood your question right. I understood that you
would like to have it at the bottom of the list always since it is a fake
register. Is this right?

In the current implementation, all numbers taken cannot be renumbered in
upcoming new features or extensions. Only taking new slots is possible. In
the case of the mentioned register it was already taken for amd64-linux.
Please correct me if I am wrong here. ;)

Cheers
-Fred

PS: Sorry for the spam, my message was sent encrypted before.

-----Original Message-----
From: Mark Kettenis [mailto:mark.kettenis@xs4all.nl]
Sent: Wednesday, August 21, 2013 4:34 PM
To: Tedeschi, Walfred
Cc: tromey@redhat.com; jan.kratochvil@redhat.com; mark.kettenis@xs4all.nl;
gdb-patches@sourceware.org; Tedeschi, Walfred
Subject: Re: [PATCH 0/7] Intel(R) MPX registers support.

> From: Walfred Tedeschi <walfred.tedeschi@intel.com>
> Date: Wed, 21 Aug 2013 14:45:41 +0200
>
> This patch series adds support for the Intel(R) Memory Protection
> Extension MPX registers. Native and remote debugging are covered by this
patch.
>
> New registers are bound registers known as bnd register (bnd0...bnd3),
> a config register bndcfgu and a status register bndstatus.  Bound
> registers store pointer bounds, i.e. bound limits of a pointer.
> Bndstatus and bndcfgu store information of the current status and
> configuration of other MPX counterparts.  For more information [1][2].
>
> Design notes:
> Bound register are represented in hardware as two fields of 64bits
> each, both in 64bit and 32bit mode. The fields are lower bound and upper
bound.
> Upper bound value is a complement of one value of the upper limiting
> address. To take this into account the bnd0...bnd3 are created as
> pseudo registers while the hardware values are stored on
bnd0raw...bnd3raw.
>
> Ok to commit?

Hi Walfred,

I had a quick look at the diffs.  Generally looks good.  There is an issue
though with how you handled the Linux-specific "orig_[er]ax"
fake register in the GDB interal register mapping.  Can you change things
such that it remains at the very hand of the internal register file?

I may not be able to do a full review of the changes in the next 2.5 weeks.
A friendly reminder somewhere after Sep 9 wouldn't hurt ;).

Cheers,

Mark
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052