From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <binutils-return-81455-listarch-binutils=sources.redhat.com@sourceware.org>
Received: (qmail 29216 invoked by alias); 8 Oct 2013 15:20:42 -0000
Mailing-List: contact binutils-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <binutils.sourceware.org>
List-Subscribe: <mailto:binutils-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/binutils/>
List-Post: <mailto:binutils@sourceware.org>
List-Help: <mailto:binutils-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: binutils-owner@sourceware.org
Received: (qmail 29206 invoked by uid 89); 8 Oct 2013 15:20:42 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=2.0 required=5.0 tests=AWL,BAYES_50,SPAM_SUBJECT,SPF_PASS autolearn=no version=3.3.2
X-HELO: nat28.tlf.novell.com
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 08 Oct 2013 15:20:41 +0000
Received: from EMEA1-MTA by nat28.tlf.novell.com	with Novell_GroupWise; Tue, 08 Oct 2013 16:20:38 +0100
Message-Id: <52543EE302000078000F9AF4@nat28.tlf.novell.com>
Date: Tue, 08 Oct 2013 15:20:00 -0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: <kirill.yukhin@intel.com>,"Binutils" <binutils@sourceware.org>
Subject: Re: [PATCH 2/6] x86/MPX: fix address size handling
References: <5254349502000078000F9A3D@nat28.tlf.novell.com> <525435BC02000078000F9A51@nat28.tlf.novell.com> <CAMe9rOrZuQRgcaUNgex=MDFjKYxsJimK1aCMqzEyM2XbZXCo4w@mail.gmail.com>
In-Reply-To: <CAMe9rOrZuQRgcaUNgex=MDFjKYxsJimK1aCMqzEyM2XbZXCo4w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SW-Source: 2013-10/txt/msg00079.txt.bz2

>>> On 08.10.13 at 17:15, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> On Tue, Oct 8, 2013 at 7:41 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> While address overrides are ignored in 64-bit mode (and hence shouldn't
>> result in an error), trying to use 16-bit addressing is documented to
>> result in #UD, and hence the assembler should reject the attempt.
>>
>> gas/
>> 2013-10-08  Jan Beulich <jbeulich@suse.com>
>>
>>         * tc-i386.c (md_assemble): Alter address size checking for MPX
>>         instructions.
>>
>> --- 2013-10-07/gas/config/tc-i386.c
>> +++ 2013-10-07/gas/config/tc-i386.c
>> @@ -3549,10 +3549,15 @@ md_assemble (char *line)
>>    if (i.bnd_prefix && !i.tm.opcode_modifier.bndprefixok)
>>      as_bad (_("expecting valid branch instruction after `bnd'"));
>>
>> -  if (i.tm.cpu_flags.bitfield.cpumpx
>> -      && flag_code =3D=3D CODE_64BIT
>> -      && i.prefix[ADDR_PREFIX])
>> -    as_bad (_("32-bit address isn't allowed in 64-bit MPX instructions.=
"));
>=20
> It is done on purpose.  When 32-bit address prefix in 64-bit is ignored,
> MPX doesn't work correctly for x32.

I don't understand: It _is_ being ignored by the hardware as per
the documentation. So x32 need to get along with that. Maybe
an example would help, so I could understand why you think
this _needs_ to be an error...

Jan

>> +  if (i.tm.cpu_flags.bitfield.cpumpx)
>> +    {
>> +      if (flag_code =3D=3D CODE_64BIT && i.prefix[ADDR_PREFIX])
>> +       as_warn (_("32-bit addressing is ignored in 64-bit MPX=20
> instructions"));
>> +      else if (flag_code !=3D CODE_16BIT
>> +              ? i.prefix[ADDR_PREFIX]
>> +              : i.mem_operands && !i.prefix[ADDR_PREFIX])
>> +       as_bad (_("16-bit addressing isn't allowed in MPX instructions")=
);
>> +    }
>>
>>    /* Insert BND prefix.  */
>>    if (add_bnd_prefix
>>
>>
>>
>=20
>=20
>=20
> --=20
> H.J.