[3/6] x86: harmonize disp with imm handling

Message ID 34a3a825-8c9f-d52b-9a1d-6cd45e051332@suse.com
State New
Headers show
Series
  • x86: further value overflow diagnostic adjustments
Related show

Commit Message

Libor Bukata via Binutils June 14, 2021, 10:25 a.m.
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.

Note that using equivalent 16-bit mode displacements / immediates
continues to expose entirely different behavior (see the disp-imm-16
testcase added by an earlier patch). This may want to be the subject of
further changes, but it'll then quickly become obvious that e.g. keying
use of extend_to_32bit_address() to non-64-bit mode isn't appropriate
either: Once we allow wrapping operands, we would better do so
consistently, in which case all of this would need to become dependent
upon address or operand size instead of mode.

gas/
2021-06-XX  Jan Beulich  <jbeulich@suse.com>

	* config/tc-i386.c (optimize_disp): Generalize disp32 part of
	the BFD64-only logic to also apply to non-64-bit code.
	(i386_finalize_displacement): Use extend_to_32bit_address for
	non-64-bit code. Drop now redundant O_constant checks.
	* testsuite/gas/i386/disp-imm-32.s,
	testsuite/gas/i386/disp-imm-32.d: New.
	* testsuite/gas/i386/i386.exp: Run new test.

---
It may remain a point for discussion whether immediates/displacements
which are obviously exceeding 32 bit (like present in the new test case)
wouldn't better trigger minimally a warning, to at least sort of match
!BFD64's "missing or invalid {displacement,immediate} expression" errors
in such cases. But telling apart expressions which have overflowed (in
32 bits) from ones where larger-than-32-bit constants were present may
end up being difficult.

Comments

Libor Bukata via Binutils June 17, 2021, 2:46 p.m. | #1
On Mon, Jun 14, 2021 at 3:25 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> 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.

>

> Note that using equivalent 16-bit mode displacements / immediates

> continues to expose entirely different behavior (see the disp-imm-16

> testcase added by an earlier patch). This may want to be the subject of

> further changes, but it'll then quickly become obvious that e.g. keying

> use of extend_to_32bit_address() to non-64-bit mode isn't appropriate

> either: Once we allow wrapping operands, we would better do so

> consistently, in which case all of this would need to become dependent

> upon address or operand size instead of mode.

>

> gas/

> 2021-06-XX  Jan Beulich  <jbeulich@suse.com>

>

>         * config/tc-i386.c (optimize_disp): Generalize disp32 part of

>         the BFD64-only logic to also apply to non-64-bit code.

>         (i386_finalize_displacement): Use extend_to_32bit_address for

>         non-64-bit code. Drop now redundant O_constant checks.

>         * testsuite/gas/i386/disp-imm-32.s,

>         testsuite/gas/i386/disp-imm-32.d: New.

>         * testsuite/gas/i386/i386.exp: Run new test.

>

> ---

> It may remain a point for discussion whether immediates/displacements

> which are obviously exceeding 32 bit (like present in the new test case)

> wouldn't better trigger minimally a warning, to at least sort of match

> !BFD64's "missing or invalid {displacement,immediate} expression" errors

> in such cases. But telling apart expressions which have overflowed (in

> 32 bits) from ones where larger-than-32-bit constants were present may

> end up being difficult.

>

> --- a/gas/config/tc-i386.c

> +++ b/gas/config/tc-i386.c

> @@ -5905,26 +5905,24 @@ optimize_disp (void)

>               }

>

>  #ifdef BFD64

> -           if (flag_code == CODE_64BIT)

> +           /* Optimize 64-bit displacement to 32-bit for 64-bit BFD.  */

> +           if ((i.types[op].bitfield.disp32

> +                || (flag_code == CODE_64BIT

> +                    && want_disp32 (current_templates->start)))

> +               && fits_in_unsigned_long (op_disp))

>               {

> -               /* Optimize 64-bit displacement to 32-bit for 64-bit BFD.  */

> -               if ((i.types[op].bitfield.disp32

> -                    || want_disp32 (current_templates->start))

> -                   && fits_in_unsigned_long (op_disp))

> -                 {

> -                   /* If this operand is at most 32 bits, convert

> -                      to a signed 32 bit number and don't use 64bit

> -                      displacement.  */

> -                   op_disp = (op_disp ^ ((offsetT) 1 << 31)) - ((addressT) 1 << 31);

> -                   i.types[op].bitfield.disp64 = 0;

> -                   i.types[op].bitfield.disp32 = 1;

> -                 }

> +               /* If this operand is at most 32 bits, convert

> +                  to a signed 32 bit number and don't use 64bit

> +                  displacement.  */

> +               op_disp = (op_disp ^ ((offsetT) 1 << 31)) - ((addressT) 1 << 31);

> +               i.types[op].bitfield.disp64 = 0;

> +               i.types[op].bitfield.disp32 = 1;

> +             }

>

> -               if (fits_in_signed_long (op_disp))

> -                 {

> -                   i.types[op].bitfield.disp64 = 0;

> -                   i.types[op].bitfield.disp32s = 1;

> -                 }

> +           if (flag_code == CODE_64BIT && fits_in_signed_long (op_disp))

> +             {

> +               i.types[op].bitfield.disp64 = 0;

> +               i.types[op].bitfield.disp32s = 1;

>               }

>  #endif

>             if ((i.types[op].bitfield.disp32

> @@ -11019,9 +11017,18 @@ i386_finalize_displacement (segT exp_seg

>        ret = 0;

>      }

>

> +  else if (exp->X_op == O_constant)

> +    {

> +      /* Sizing gets taken care of by optimize_disp().

> +

> +        If not 64bit, sign/zero extend val, to account for wraparound

> +        when !BFD64.  */

> +      if (flag_code != CODE_64BIT)

> +       exp->X_add_number = extend_to_32bit_address (exp->X_add_number);

> +    }

> +

>  #if (defined (OBJ_AOUT) || defined (OBJ_MAYBE_AOUT))

> -  else if (exp->X_op != O_constant

> -          && OUTPUT_FLAVOR == bfd_target_aout_flavour

> +  else if (OUTPUT_FLAVOR == bfd_target_aout_flavour

>            && exp_seg != absolute_section

>            && exp_seg != text_section

>            && exp_seg != data_section

> @@ -11034,9 +11041,7 @@ i386_finalize_displacement (segT exp_seg

>      }

>  #endif

>

> -  if (current_templates->start->opcode_modifier.jump == JUMP_BYTE

> -      /* Constants get taken care of by optimize_disp().  */

> -      && exp->X_op != O_constant)

> +  else if (current_templates->start->opcode_modifier.jump == JUMP_BYTE)

>      i.types[this_operand].bitfield.disp8 = 1;

>

>    /* Check if this is a displacement only operand.  */

> --- /dev/null

> +++ b/gas/testsuite/gas/i386/disp-imm-32.d

> @@ -0,0 +1,21 @@

> +#objdump: -dw

> +#name: i386 displacements / immediates (32-bit)

> +

> +.*: +file format .*

> +

> +Disassembly of section .text:

> +

> +0+ <disp_imm>:

> +[      ]*[a-f0-9]+:    8b 40 01                mov    0x1\(%eax\),%eax

> +[      ]*[a-f0-9]+:    62 f1 7c 48 28 40 01    vmovaps 0x40\(%eax\),%zmm0

> +[      ]*[a-f0-9]+:    83 c1 01                add    \$0x1,%ecx

> +[      ]*[a-f0-9]+:    8b 00                   mov    \(%eax\),%eax

> +[      ]*[a-f0-9]+:    62 f1 7c 48 28 00       vmovaps \(%eax\),%zmm0

> +[      ]*[a-f0-9]+:    83 c1 00                add    \$0x0,%ecx

> +[      ]*[a-f0-9]+:    8b 40 ff                mov    -0x1\(%eax\),%eax

> +[      ]*[a-f0-9]+:    62 f1 7c 48 28 40 ff    vmovaps -0x40\(%eax\),%zmm0

> +[      ]*[a-f0-9]+:    83 c1 ff                add    \$0xffffffff,%ecx

> +[      ]*[a-f0-9]+:    8b 40 01                mov    0x1\(%eax\),%eax

> +[      ]*[a-f0-9]+:    62 f1 7c 48 28 40 01    vmovaps 0x40\(%eax\),%zmm0

> +[      ]*[a-f0-9]+:    83 c1 01                add    \$0x1,%ecx

> +#pass

> --- /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.

> +       vmovaps -0xffffffc0(%eax), %zmm0

> +       add     $-0xffffffff, %ecx

> +

> +       mov     -0xffffffff-1(%eax), %eax

> +       vmovaps -0xffffffc0-0x40(%eax), %zmm0

> +       add     $-0xffffffff-1, %ecx

> +

> +       mov     -0xffffffff-2(%eax), %eax

> +       vmovaps -0xffffffc0-0x80(%eax), %zmm0

> +       add     $-0xffffffff-2, %ecx

> +

> +       mov     -0x1ffffffff(%eax), %eax

> +       vmovaps -0x1ffffffc0(%eax), %zmm0

> +       add     $-0x1ffffffff, %ecx

> --- a/gas/testsuite/gas/i386/i386.exp

> +++ b/gas/testsuite/gas/i386/i386.exp

> @@ -88,6 +88,9 @@ if [gas_32_check] then {

>      run_dump_test "disp-intel"

>      run_dump_test "disp32"

>      run_list_test "disp-imm-16"

> +    if { [gas_bfd64_check] } {

> +       run_dump_test "disp-imm-32"

> +    }

>      run_dump_test "vmx"

>      run_dump_test "vmfunc"

>      run_dump_test "smx"

>



-- 
H.J.
Libor Bukata via Binutils June 17, 2021, 2:57 p.m. | #2
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).

Jan
Libor Bukata via Binutils June 17, 2021, 4 p.m. | #3
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.

-- 
H.J.
Libor Bukata via Binutils June 17, 2021, 4:05 p.m. | #4
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)).

Jan
Libor Bukata via Binutils June 17, 2021, 4:12 p.m. | #5
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.

-- 
H.J.
Libor Bukata via Binutils June 18, 2021, 9:03 a.m. | #6
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
Libor Bukata via Binutils June 18, 2021, 2:12 p.m. | #7
On Fri, Jun 18, 2021 at 2:03 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> 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?

>


If the program wants 1, use 1.  DISP treatment should stay as is.

-- 
H.J.
Libor Bukata via Binutils June 18, 2021, 2:52 p.m. | #8
On 18.06.2021 16:12, H.J. Lu wrote:
> On Fri, Jun 18, 2021 at 2:03 AM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> 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?

> 

> 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:

"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)."

If what you say were true for disp, why would it not also apply to
imm? In the end, an imm loaded into a register may very well be
used to access memory, i.e. possibly fulfills the purpose of a disp.
We shouldn't force people to write quirky code just because gas
accepts certain things for imm which it doesn't accept for disp.

Jan
Libor Bukata via Binutils June 18, 2021, 3:41 p.m. | #9
On Fri, Jun 18, 2021 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 18.06.2021 16:12, H.J. Lu wrote:

> > On Fri, Jun 18, 2021 at 2:03 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>

> >> 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?

> >

> > 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.

> "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)."

>

> If what you say were true for disp, why would it not also apply to

> imm? In the end, an imm loaded into a register may very well be

> used to access memory, i.e. possibly fulfills the purpose of a disp.

> We shouldn't force people to write quirky code just because gas

> accepts certain things for imm which it doesn't accept for disp.

>


Loading imm into register is similar to wraparound in C.  DISP
is different.

-- 
H.J.
Libor Bukata via Binutils June 21, 2021, 6:36 a.m. | #10
On 18.06.2021 17:41, H.J. Lu wrote:
> On Fri, Jun 18, 2021 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> On 18.06.2021 16:12, H.J. Lu wrote:

>>> On Fri, Jun 18, 2021 at 2:03 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>

>>>> 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?

>>>

>>> 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?

Jan
Libor Bukata via Binutils June 21, 2021, 1:26 p.m. | #11
On Sun, Jun 20, 2021 at 11:36 PM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 18.06.2021 17:41, H.J. Lu wrote:

> > On Fri, Jun 18, 2021 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>

> >> On 18.06.2021 16:12, H.J. Lu wrote:

> >>> On Fri, Jun 18, 2021 at 2:03 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>

> >>>> 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?

> >>>

> >>> 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.
Libor Bukata via Binutils June 21, 2021, 3:05 p.m. | #12
On 21.06.2021 15:26, H.J. Lu wrote:
> On Sun, Jun 20, 2021 at 11:36 PM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> On 18.06.2021 17:41, H.J. Lu wrote:

>>> On Fri, Jun 18, 2021 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>

>>>> On 18.06.2021 16:12, H.J. Lu wrote:

>>>>> On Fri, Jun 18, 2021 at 2:03 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>>

>>>>>> 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?

>>>>>

>>>>> 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.


You still didn't understand, it seems: This wrapping was there before.
All I did is make it consistently silent, and generate consistent code.

>   Please find another way to make disp consistent.


I don't see any.

Jan
Michael Matz June 22, 2021, 1:22 p.m. | #13
Hello,

On Fri, 18 Jun 2021, H.J. Lu via Binutils wrote:

> > 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.


The assembler should not be too much in the business of constraining users 
with well-intended but badly implemented rules.  The -0xffffffff isn't 
actually a literal, it's an (assembler) operation applied to a literal.  
The wraparound that does or doesn't happen is _internal_ to the assembler, 
the hardware doesn't enter the picture.  -0xffffffff only means '1' 
because the assembler internally represents this as 32bit entity, again 
without the hardware mattering.  (And if it were using a different-sized 
internal field it would or wouldn't warn on different input ranges, and if 
that size then depends on how BFD is configured that would be very bad).

Further it's quite probable that the '-' actually comes from e.g. a macro 
expansion, it's for instance feasible to write a macro that offsets 
something by a constant in both directions:

#define sub2(reg, B, D) \
  movq D(B), reg \
  addq -D(B), reg

Now it's completely opaque why the user should be warned about this:

  sub2(%rax, %rdi, 0xffffffff)

but not about this:

  sub2(%rax, %rdi, 1)

What you are saying is equivalent to say to also warn about uses of '--1', 
after all the user "should have simply used "1"'.  Extended such makes it 
obvious that the warning is unwarranted, because then there wouldn't even 
be a work-around for the above situation anymore, you can't write 
sub2(%rax,%rdi,0xffffffff) and you can't write sub2(%rax,%rdi,-1).

I would perhaps agree that if a user literally would write '-0xffffffff' 
except in a testcase that a warning might be appropriate, in something 
that's designed to teach good style to assembler programmers perhaps.  But 
not in GNU as.  It would be a warning that can't be silenced and happens 
in perfectly valid code, so, no.

All in all: I think the assembler should be entirely silent about any of 
these literals modified by assembler operations.


Ciao,
Michael.
Libor Bukata via Binutils June 22, 2021, 2:01 p.m. | #14
On Tue, Jun 22, 2021 at 6:22 AM Michael Matz <matz@suse.de> wrote:
>

> Hello,

>

> On Fri, 18 Jun 2021, H.J. Lu via Binutils wrote:

>

> > > 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.

>

> The assembler should not be too much in the business of constraining users

> with well-intended but badly implemented rules.  The -0xffffffff isn't

> actually a literal, it's an (assembler) operation applied to a literal.

> The wraparound that does or doesn't happen is _internal_ to the assembler,

> the hardware doesn't enter the picture.  -0xffffffff only means '1'

> because the assembler internally represents this as 32bit entity, again

> without the hardware mattering.  (And if it were using a different-sized

> internal field it would or wouldn't warn on different input ranges, and if

> that size then depends on how BFD is configured that would be very bad).

>

> Further it's quite probable that the '-' actually comes from e.g. a macro

> expansion, it's for instance feasible to write a macro that offsets

> something by a constant in both directions:

>

> #define sub2(reg, B, D) \

>   movq D(B), reg \

>   addq -D(B), reg

>

> Now it's completely opaque why the user should be warned about this:

>

>   sub2(%rax, %rdi, 0xffffffff)

>

> but not about this:

>

>   sub2(%rax, %rdi, 1)

>

> What you are saying is equivalent to say to also warn about uses of '--1',

> after all the user "should have simply used "1"'.  Extended such makes it

> obvious that the warning is unwarranted, because then there wouldn't even

> be a work-around for the above situation anymore, you can't write

> sub2(%rax,%rdi,0xffffffff) and you can't write sub2(%rax,%rdi,-1).

>

> I would perhaps agree that if a user literally would write '-0xffffffff'

> except in a testcase that a warning might be appropriate, in something

> that's designed to teach good style to assembler programmers perhaps.  But

> not in GNU as.  It would be a warning that can't be silenced and happens

> in perfectly valid code, so, no.

>

> All in all: I think the assembler should be entirely silent about any of

> these literals modified by assembler operations.


A 32bit displacement is signed with R_X86_64_32S.  For

mov disp(%rax), %eax

should linker issue an error if disp == -0xffffffff?

-- 
H.J.
Libor Bukata via Binutils June 22, 2021, 2:32 p.m. | #15
On 22.06.2021 16:01, H.J. Lu wrote:
> On Tue, Jun 22, 2021 at 6:22 AM Michael Matz <matz@suse.de> wrote:

>>

>> Hello,

>>

>> On Fri, 18 Jun 2021, H.J. Lu via Binutils wrote:

>>

>>>> 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.

>>

>> The assembler should not be too much in the business of constraining users

>> with well-intended but badly implemented rules.  The -0xffffffff isn't

>> actually a literal, it's an (assembler) operation applied to a literal.

>> The wraparound that does or doesn't happen is _internal_ to the assembler,

>> the hardware doesn't enter the picture.  -0xffffffff only means '1'

>> because the assembler internally represents this as 32bit entity, again

>> without the hardware mattering.  (And if it were using a different-sized

>> internal field it would or wouldn't warn on different input ranges, and if

>> that size then depends on how BFD is configured that would be very bad).

>>

>> Further it's quite probable that the '-' actually comes from e.g. a macro

>> expansion, it's for instance feasible to write a macro that offsets

>> something by a constant in both directions:

>>

>> #define sub2(reg, B, D) \

>>   movq D(B), reg \

>>   addq -D(B), reg

>>

>> Now it's completely opaque why the user should be warned about this:

>>

>>   sub2(%rax, %rdi, 0xffffffff)

>>

>> but not about this:

>>

>>   sub2(%rax, %rdi, 1)

>>

>> What you are saying is equivalent to say to also warn about uses of '--1',

>> after all the user "should have simply used "1"'.  Extended such makes it

>> obvious that the warning is unwarranted, because then there wouldn't even

>> be a work-around for the above situation anymore, you can't write

>> sub2(%rax,%rdi,0xffffffff) and you can't write sub2(%rax,%rdi,-1).

>>

>> I would perhaps agree that if a user literally would write '-0xffffffff'

>> except in a testcase that a warning might be appropriate, in something

>> that's designed to teach good style to assembler programmers perhaps.  But

>> not in GNU as.  It would be a warning that can't be silenced and happens

>> in perfectly valid code, so, no.

>>

>> All in all: I think the assembler should be entirely silent about any of

>> these literals modified by assembler operations.

> 

> A 32bit displacement is signed with R_X86_64_32S.  For

> 

> mov disp(%rax), %eax

> 

> should linker issue an error if disp == -0xffffffff?


I think so, yes. In fact I'd hope the assembler would already not allow
this, -0xffffffff actually being 0xffffffff00000001 in 64-bit arithmetic.
What we've been discussing here so far were issues with 32-bit addressing
(and wrapping of involved arithmetic).

Jan
Michael Matz June 22, 2021, 2:35 p.m. | #16
Hello,

On Tue, 22 Jun 2021, H.J. Lu wrote:

> > All in all: I think the assembler should be entirely silent about any of

> > these literals modified by assembler operations.

> 

> A 32bit displacement is signed with R_X86_64_32S.  For

> 

> mov disp(%rax), %eax

> 

> should linker issue an error if disp == -0xffffffff?


The linker doesn't see '-0xffffffff', it sees a bit pattern that it 
interprets in some way as a single number.  When we write down the bit 
pattern as unsigned hex, it will for instance see (in the above case when 
the width is 32bit and the assembler did the obvious thing) '1' (i.e. 
something that the linker can't differentiate from what was produced by 
the assembler on a simple literal '1' input).  There is no unary minus 
operation on linker input.


Ciao,
Michael.

Patch

--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -5905,26 +5905,24 @@  optimize_disp (void)
 	      }
 
 #ifdef BFD64
-	    if (flag_code == CODE_64BIT)
+	    /* Optimize 64-bit displacement to 32-bit for 64-bit BFD.  */
+	    if ((i.types[op].bitfield.disp32
+		 || (flag_code == CODE_64BIT
+		     && want_disp32 (current_templates->start)))
+		&& fits_in_unsigned_long (op_disp))
 	      {
-		/* Optimize 64-bit displacement to 32-bit for 64-bit BFD.  */
-		if ((i.types[op].bitfield.disp32
-		     || want_disp32 (current_templates->start))
-		    && fits_in_unsigned_long (op_disp))
-		  {
-		    /* If this operand is at most 32 bits, convert
-		       to a signed 32 bit number and don't use 64bit
-		       displacement.  */
-		    op_disp = (op_disp ^ ((offsetT) 1 << 31)) - ((addressT) 1 << 31);
-		    i.types[op].bitfield.disp64 = 0;
-		    i.types[op].bitfield.disp32 = 1;
-		  }
+		/* If this operand is at most 32 bits, convert
+		   to a signed 32 bit number and don't use 64bit
+		   displacement.  */
+		op_disp = (op_disp ^ ((offsetT) 1 << 31)) - ((addressT) 1 << 31);
+		i.types[op].bitfield.disp64 = 0;
+		i.types[op].bitfield.disp32 = 1;
+	      }
 
-		if (fits_in_signed_long (op_disp))
-		  {
-		    i.types[op].bitfield.disp64 = 0;
-		    i.types[op].bitfield.disp32s = 1;
-		  }
+	    if (flag_code == CODE_64BIT && fits_in_signed_long (op_disp))
+	      {
+		i.types[op].bitfield.disp64 = 0;
+		i.types[op].bitfield.disp32s = 1;
 	      }
 #endif
 	    if ((i.types[op].bitfield.disp32
@@ -11019,9 +11017,18 @@  i386_finalize_displacement (segT exp_seg
       ret = 0;
     }
 
+  else if (exp->X_op == O_constant)
+    {
+      /* Sizing gets taken care of by optimize_disp().
+
+	 If not 64bit, sign/zero extend val, to account for wraparound
+	 when !BFD64.  */
+      if (flag_code != CODE_64BIT)
+	exp->X_add_number = extend_to_32bit_address (exp->X_add_number);
+    }
+
 #if (defined (OBJ_AOUT) || defined (OBJ_MAYBE_AOUT))
-  else if (exp->X_op != O_constant
-	   && OUTPUT_FLAVOR == bfd_target_aout_flavour
+  else if (OUTPUT_FLAVOR == bfd_target_aout_flavour
 	   && exp_seg != absolute_section
 	   && exp_seg != text_section
 	   && exp_seg != data_section
@@ -11034,9 +11041,7 @@  i386_finalize_displacement (segT exp_seg
     }
 #endif
 
-  if (current_templates->start->opcode_modifier.jump == JUMP_BYTE
-      /* Constants get taken care of by optimize_disp().  */
-      && exp->X_op != O_constant)
+  else if (current_templates->start->opcode_modifier.jump == JUMP_BYTE)
     i.types[this_operand].bitfield.disp8 = 1;
 
   /* Check if this is a displacement only operand.  */
--- /dev/null
+++ b/gas/testsuite/gas/i386/disp-imm-32.d
@@ -0,0 +1,21 @@ 
+#objdump: -dw
+#name: i386 displacements / immediates (32-bit)
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+ <disp_imm>:
+[ 	]*[a-f0-9]+:	8b 40 01             	mov    0x1\(%eax\),%eax
+[ 	]*[a-f0-9]+:	62 f1 7c 48 28 40 01 	vmovaps 0x40\(%eax\),%zmm0
+[ 	]*[a-f0-9]+:	83 c1 01             	add    \$0x1,%ecx
+[ 	]*[a-f0-9]+:	8b 00                	mov    \(%eax\),%eax
+[ 	]*[a-f0-9]+:	62 f1 7c 48 28 00    	vmovaps \(%eax\),%zmm0
+[ 	]*[a-f0-9]+:	83 c1 00             	add    \$0x0,%ecx
+[ 	]*[a-f0-9]+:	8b 40 ff             	mov    -0x1\(%eax\),%eax
+[ 	]*[a-f0-9]+:	62 f1 7c 48 28 40 ff 	vmovaps -0x40\(%eax\),%zmm0
+[ 	]*[a-f0-9]+:	83 c1 ff             	add    \$0xffffffff,%ecx
+[ 	]*[a-f0-9]+:	8b 40 01             	mov    0x1\(%eax\),%eax
+[ 	]*[a-f0-9]+:	62 f1 7c 48 28 40 01 	vmovaps 0x40\(%eax\),%zmm0
+[ 	]*[a-f0-9]+:	83 c1 01             	add    \$0x1,%ecx
+#pass
--- /dev/null
+++ b/gas/testsuite/gas/i386/disp-imm-32.s
@@ -0,0 +1,17 @@ 
+	.text
+disp_imm:
+	mov	-0xffffffff(%eax), %eax
+	vmovaps	-0xffffffc0(%eax), %zmm0
+	add	$-0xffffffff, %ecx
+
+	mov	-0xffffffff-1(%eax), %eax
+	vmovaps	-0xffffffc0-0x40(%eax), %zmm0
+	add	$-0xffffffff-1, %ecx
+
+	mov	-0xffffffff-2(%eax), %eax
+	vmovaps	-0xffffffc0-0x80(%eax), %zmm0
+	add	$-0xffffffff-2, %ecx
+
+	mov	-0x1ffffffff(%eax), %eax
+	vmovaps	-0x1ffffffc0(%eax), %zmm0
+	add	$-0x1ffffffff, %ecx
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -88,6 +88,9 @@  if [gas_32_check] then {
     run_dump_test "disp-intel"
     run_dump_test "disp32"
     run_list_test "disp-imm-16"
+    if { [gas_bfd64_check] } {
+	run_dump_test "disp-imm-32"
+    }
     run_dump_test "vmx"
     run_dump_test "vmfunc"
     run_dump_test "smx"