From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id ED72B393BC2F for ; Mon, 21 Jun 2021 13:26:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ED72B393BC2F Received: by mail-pf1-x431.google.com with SMTP id a127so3097418pfa.10 for ; Mon, 21 Jun 2021 06:26:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/Vz7wKQuE1nRe0Mrukp3RxqHmsKKkNLsD/0voM+CFRY=; b=MZ6PuVor/c2CQhJtwXnc58eH+wWwwAX2mzVVuTL9NQWZytyjwjSYKTXw8+5eTG1Oyp H+exrPbB+5DpsSxOFkUZXhtmRv39ndrQQlovzH6QJRODXeWIBr0oMW0QXdssFRTLqKTP hcc4V7+RfnBHYbhApV6A5Jl2InHaFJXrUovx4nhfbyLhgYlWk9dsBCnipDvTjBxJlweM j2D9RgCpPMgfyo7JHSwKB+zKC0EsGYRIiNwOcwPL4L2xgYbE2kkgipyLIzafKCy59GiJ wYGzMhdPFaG7NXcPcSEDuGxiypKyZearr7c2uVAA63nRCa+xkx2RWAErbXSK+AL2G6FW QMPQ== X-Gm-Message-State: AOAM532PHCcrXaaDlxT+ikAuqnpmyX1gHZ4H7PAa5xwNXXmh3GddYuFU XwDWVCh5SODxlwYrSarznA72BTZhBjvxdfqlm8w= X-Google-Smtp-Source: ABdhPJyXayHj/uhnjfAyJEdFTJjIZV0y9E3crfnxCR2v8EUqZSZCbaZmWutl2mozm8htr2/ymhVJWQlyG/caaAx0pwg= X-Received: by 2002:a62:e908:0:b029:2db:8791:c217 with SMTP id j8-20020a62e9080000b02902db8791c217mr20048368pfh.28.1624281998083; Mon, 21 Jun 2021 06:26:38 -0700 (PDT) MIME-Version: 1.0 References: <0babbec4-06ae-f980-18a9-20608046891b@suse.com> <34a3a825-8c9f-d52b-9a1d-6cd45e051332@suse.com> <803f03a4-bb6d-5580-b2ff-b1df2d5152f3@suse.com> <9212df8b-01cf-0c0c-45c3-39de3dcf1bd9@suse.com> In-Reply-To: From: "H.J. Lu" Date: Mon, 21 Jun 2021 06:26:02 -0700 Message-ID: Subject: Re: [PATCH 3/6] x86: harmonize disp with imm handling To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3026.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 13:26:40 -0000 On Sun, Jun 20, 2021 at 11:36 PM Jan Beulich wrote: > > On 18.06.2021 17:41, H.J. Lu wrote: > > On Fri, Jun 18, 2021 at 7:52 AM Jan Beulich wrote: > >> > >> On 18.06.2021 16:12, H.J. Lu wrote: > >>> On Fri, Jun 18, 2021 at 2:03 AM Jan Beulich wrote: > >>>> > >>>> On 17.06.2021 18:12, H.J. Lu wrote: > >>>>> On Thu, Jun 17, 2021 at 9:05 AM Jan Beulich wrote: > >>>>>> > >>>>>> On 17.06.2021 18:00, H.J. Lu wrote: > >>>>>>> On Thu, Jun 17, 2021 at 7:57 AM Jan Beulich wrote: > >>>>>>>> > >>>>>>>> On 17.06.2021 16:46, H.J. Lu wrote: > >>>>>>>>> On Mon, Jun 14, 2021 at 3:25 AM Jan Beulich wrote: > >>>>>>>>>> --- /dev/null > >>>>>>>>>> +++ b/gas/testsuite/gas/i386/disp-imm-32.s > >>>>>>>>>> @@ -0,0 +1,17 @@ > >>>>>>>>>> + .text > >>>>>>>>>> +disp_imm: > >>>>>>>>>> + mov -0xffffffff(%eax), %eax > >>>>>>>>> > >>>>>>>>> I don't think we should treat -0xffffffff(%eax) as 1(%eax). > >>>>>>>>> We allow addresses to wraparound. I don't see a need for > >>>>>>>>> displacements to wraparound. > >>>>>>>> > >>>>>>>> This then is entirely unexpected to the programmer. In fact the > >>>>>>>> same (abstracted away behind some defines or equates) constant > >>>>>>>> could be used for both purposes (and should be usable both ways, > >>>>>>>> imo). > >>>>>>> > >>>>>>> Since hardware wraparound on DISP + BASE + INDEX * SCALE, not > >>>>>>> on DISP, it is wrong to change DISP + BASE + INDEX * SCALE to > >>>>>>> wraparound (DISP) + BASE + INDEX * SCALE. > >>>>>> > >>>>>> But this is true regardless of how small (or big) the displacement. > >>>>>> Without knowing the register values, you can't know at what > >>>>>> displacement values wraparound occurs. Also, unless I'm mistaken, > >>>>>> wrapround(a + b) == wrapround(wrapround(a) + wrapround(b)). > >>>>> > >>>>> Hardware does wraparound (DISP + BASE + INDEX * SCALE). > >>>>> Assembler and linker should only wraparound on the final address. > >>>> > >>>> I'm afraid this last sentence makes no sense to me: The assembler > >>>> (or linker) can't know the final address. Instead, both immediates > >>>> and displacements should allow for anything the programmer might > >>>> sensibly use. If 0xffffffff as a displacement is fine (meaning > >>>> -1 really), -0xffffffff (meaning 1) ought to be, too. Or else > >>>> where do you draw the boundary of which displacements are > >>>> "legitimate" and which are not? > >>> > >>> If the program wants 1, use 1. > >> > >> You realize that for the purpose of the test case the -0xffffffff is > >> an over-simplification of what might appear in "real" code, don't > >> you? It also feels as if you didn't really read my earlier remark: > > > > I don't think treating -0xffffffff as 1 here helps anyone. > > I'm afraid I was utterly mislead by your commentary here. There's no > change from this patch in the numeric meaning of -0xffffffff. The > change here is what warnings result and what encodings get used. As > the description says: > > 'Certain disp values may trigger "... shortened to ..." warnings when > equivalent imm ones don't. In some of the cases there are also > differences (for non-64-bit code) between BFD64 and !BFD64 builds. The > resulting encodings (i.e. use [or not] of the shorter disp8 / imm8 > forms) are also different in some cases. Make this handling consistent.' > > Please may I ask that you take the new testcase and observe the > difference in behavior with / without BFD64 prior to this patch, and > the now consistent one? Make disp consistent is good. But wraparound disp is not. Please find another way to make disp consistent. -- H.J.