From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <binutils-return-105413-listarch-binutils=sources.redhat.com@sourceware.org>
Received: (qmail 59034 invoked by alias); 29 Apr 2019 07:01:07 -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 59024 invoked by uid 89); 29 Apr 2019 07:01:07 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=H*UA:Internet
X-HELO: prv1-mh.provo.novell.com
Received: from prv1-mh.provo.novell.com (HELO prv1-mh.provo.novell.com) (137.65.248.33) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Apr 2019 07:01:02 +0000
Received: from INET-PRV1-MTA by prv1-mh.provo.novell.com	with Novell_GroupWise; Mon, 29 Apr 2019 01:01:00 -0600
Message-Id: <5CC6A1280200007800229D48@prv1-mh.provo.novell.com>
Date: Mon, 29 Apr 2019 07:01:00 -0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: <binutils@sourceware.org>
Subject: Re: [PATCH] i386: Don't add 0x66 prefix to IRET for .code16gcc
References: <20190426172207.13838-1-hjl.tools@gmail.com>
In-Reply-To: <20190426172207.13838-1-hjl.tools@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SW-Source: 2019-04/txt/msg00251.txt.bz2

>>> On 26.04.19 at 19:22, <hjl.tools@gmail.com> wrote:
> The .code16gcc directive supports 16bit mode with 32-bit address.  Since
> IRET (opcode 0xcf) in 16bit mode returns from an interrupt in 16bit mode,
> we shouldn't add 0x66 prefix for IRET.
>=20
> 	PR gas/24485
> 	* config/tc-i386.c (process_suffix): Don't add DATA_PREFIX_OPCODE
> 	to IRET for .code16gcc.

This, at the very least, needs to be accompanied by a warning:
As the bug report validly says, the changed behavior is what is
wanted only "almost always". The report even mentions the
(supposedly uncommon) case: Code manually building a frame
and IRETing to it will now be silently(!) broken.

In fact I think the better solution would be to reject ambiguous
code by demanding a suffix in all cases in .code16gcc mode.

Jan