public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Binutils <binutils@sourceware.org>
Subject: Re: [PATCH 3/6] x86: harmonize disp with imm handling
Date: Fri, 18 Jun 2021 11:03:15 +0200	[thread overview]
Message-ID: <c58e129a-6475-9358-49e3-5ba2f3f5405b@suse.com> (raw)
In-Reply-To: <CAMe9rOrgXQ6NmibZ=fwMb1_e0K4_zjUJBMCejW9_pS3fbXAYPw@mail.gmail.com>

On 17.06.2021 18:12, H.J. Lu wrote:
> On Thu, Jun 17, 2021 at 9:05 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 17.06.2021 18:00, H.J. Lu wrote:
>>> On Thu, Jun 17, 2021 at 7:57 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 17.06.2021 16:46, H.J. Lu wrote:
>>>>> On Mon, Jun 14, 2021 at 3:25 AM Jan Beulich <jbeulich@suse.com> 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?

Jan


  reply	other threads:[~2021-06-18  9:03 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-14 10:23 [PATCH 0/6] x86: further value overflow diagnostic adjustments Jan Beulich
2021-06-14 10:24 ` [PATCH 1/6] x86: off-by-1 in offset_in_range() Jan Beulich
2021-06-17 14:40   ` H.J. Lu
2021-06-18 10:48     ` Jan Beulich
2021-06-14 10:25 ` [PATCH 2/6] x86: make offset_in_range()'s warning contents useful (again) Jan Beulich
2021-06-17 14:40   ` H.J. Lu
2021-06-14 10:25 ` [PATCH 3/6] x86: harmonize disp with imm handling Jan Beulich
2021-06-17 14:46   ` H.J. Lu
2021-06-17 14:57     ` Jan Beulich
2021-06-17 16:00       ` H.J. Lu
2021-06-17 16:05         ` Jan Beulich
2021-06-17 16:12           ` H.J. Lu
2021-06-18  9:03             ` Jan Beulich [this message]
2021-06-18 14:12               ` H.J. Lu
2021-06-18 14:52                 ` Jan Beulich
2021-06-18 15:41                   ` H.J. Lu
2021-06-21  6:36                     ` Jan Beulich
2021-06-21 13:26                       ` H.J. Lu
2021-06-21 15:05                         ` Jan Beulich
2021-06-22 13:22                     ` Michael Matz
2021-06-22 14:01                       ` H.J. Lu
2021-06-22 14:32                         ` Jan Beulich
2021-06-22 14:35                         ` Michael Matz
2021-06-14 10:26 ` [PATCH 4/6] x86: slightly simplify offset_in_range() Jan Beulich
2021-06-17 14:46   ` H.J. Lu
2021-06-14 10:26 ` [PATCH 5/6] x86: simplify .dispNN setting Jan Beulich
2021-06-17 14:47   ` H.J. Lu
2021-06-14 10:26 ` [PATCH 6/6] x86: bring "gas --help" output for --32 etc in sync with reality Jan Beulich
2021-06-17 14:48   ` H.J. Lu
2021-06-14 14:41 ` [PATCH 0/6] x86: further value overflow diagnostic adjustments H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c58e129a-6475-9358-49e3-5ba2f3f5405b@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).