From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72998 invoked by alias); 29 Apr 2019 16:11:41 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 72989 invoked by uid 89); 29 Apr 2019 16:11:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=H*f:sk:vraPhkr, H*i:sk:A@mail., H*f:CAMe9rOp9yfg, H*i:CAMe9rOp9yfg 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 16:11:39 +0000 Received: from INET-PRV1-MTA by prv1-mh.provo.novell.com with Novell_GroupWise; Mon, 29 Apr 2019 10:11:38 -0600 Message-Id: <5CC72236020000780022A212@prv1-mh.provo.novell.com> Date: Mon, 29 Apr 2019 16:11:00 -0000 From: "Jan Beulich" To: "H.J. Lu" Cc: Subject: Re: [PATCH] i386: Don't add 0x66 prefix to IRET for .code16gcc References: <20190426172207.13838-1-hjl.tools@gmail.com> <5CC6A1280200007800229D48@prv1-mh.provo.novell.com> <5CC7174A020000780022A168@prv1-mh.provo.novell.com> In-Reply-To: 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/msg00259.txt.bz2 >>> On 29.04.19 at 18:02, wrote: > On Mon, Apr 29, 2019 at 8:25 AM Jan Beulich wrote: >> >> >>> On 29.04.19 at 17:09, wrote: >> > On Mon, Apr 29, 2019 at 12:01 AM Jan Beulich wrote: >> >> >>> On 26.04.19 at 19:22, 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. >> >> > >> >> > PR gas/24485 >> >> > * config/tc-i386.c (process_suffix): Don't add DATA_PREFIX_OP= CODE >> >> > to IRET for .code16gcc. >> >> >> >> This, at the very least, needs to be accompanied by a warning: >> > >> > This patch fixes: >> >[...] >> >> 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. >> > >> > The .code16gcc directive is to support "gcc -m16". Any other purposes >> > are not supported. >> >> But you realize that people may use inline assembly? >=20 > Inline assembly with the .code16gcc directive in an interrupt > handler? It is a supported usage? I don't know, but I see no reasons why it would not be. Note that I didn't mention "in an interrupt handler" - I can see uses for manually created frames to IRET to elsewhere. >> >> In fact I think the better solution would be to reject ambiguous >> >> code by demanding a suffix in all cases in .code16gcc mode. >> > >> > This may break existing codes. >> >> Of course, but breaking things at build time (with a proper >> diagnostic) that's better than silently breaking things at >> runtime. At the very least you can't claim it would break the >> supposedly common case, as that was already broken (and >> hence your fix). So the difference between suggested >> and current behavior is that right now there's silent latent >> breakage, whereas otherwise people would be made aware >> of there being a problem they need to address by changing >> some of their code. >=20 > Assembler has no way to know if an assembly sequence is > correct and it shouldn't issue a warning for "gcc -m16" just > because the same instruction may be incorrect. I disagree: In this case, the assembler simply can't decide whether adding an operand size override is correct. Instead of silently doing the opposite of what has been done for many years, it should point out that it needs programmer guidance. Jan