offset_in_range() question

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

offset_in_range() question

Jan Beulich-2
H.J.,

the dependency on presence of an address size override, when the
function is also used on immediate operands, struck me as being
a possible source for problems. On 2009-09-15 you've made two
changes to the construct in question, but I wonder whether even
back then this code wasn't already dead. When, after quite a bit
of playing, I couldn't come up with any immediate that this
would go wrong on, I thought I'll give a try to removing that
code altogether. And indeed - no fallout. Looking more closely
then suggested that respective logic in optimize_imm() and
optimize_disp() are already arranging for values to never need
further massaging here.

Do you agree that the code could be removed (see patch below in
case of any uncertainty about what block of code I mean), or are
you aware of things that might break this way?

As an aside, I don't think the handling of out-of-range
immediates is quite correct, but I'll get to this in more detail
after thinking some more on possible solutions.

Jan

--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -2539,14 +2539,6 @@ offset_in_range (offsetT val, int size)
     default: abort ();
     }
 
-#ifdef BFD64
-  /* If BFD64, sign extend val for 32bit address mode.  */
-  if (flag_code != CODE_64BIT
-      || i.prefix[ADDR_PREFIX])
-    if ((val & ~(((addressT) 2 << 31) - 1)) == 0)
-      val = (val ^ ((addressT) 1 << 31)) - ((addressT) 1 << 31);
-#endif
-
   if ((val & ~mask) != 0 && (val & ~mask) != ~mask)
     {
       char buf1[40], buf2[40];
Reply | Threaded
Open this post in threaded view
|

Re: offset_in_range() question

Sourceware - binutils list mailing list
On Mon, Jul 13, 2020 at 5:50 AM Jan Beulich <[hidden email]> wrote:

>
> H.J.,
>
> the dependency on presence of an address size override, when the
> function is also used on immediate operands, struck me as being
> a possible source for problems. On 2009-09-15 you've made two
> changes to the construct in question, but I wonder whether even
> back then this code wasn't already dead. When, after quite a bit
> of playing, I couldn't come up with any immediate that this
> would go wrong on, I thought I'll give a try to removing that
> code altogether. And indeed - no fallout. Looking more closely
> then suggested that respective logic in optimize_imm() and
> optimize_disp() are already arranging for values to never need
> further massaging here.
>
> Do you agree that the code could be removed (see patch below in
> case of any uncertainty about what block of code I mean), or are
> you aware of things that might break this way?
>
> As an aside, I don't think the handling of out-of-range
> immediates is quite correct, but I'll get to this in more detail
> after thinking some more on possible solutions.
>
> Jan
>
> --- a/gas/config/tc-i386.c
> +++ b/gas/config/tc-i386.c
> @@ -2539,14 +2539,6 @@ offset_in_range (offsetT val, int size)
>      default: abort ();
>      }
>
> -#ifdef BFD64
> -  /* If BFD64, sign extend val for 32bit address mode.  */
> -  if (flag_code != CODE_64BIT
> -      || i.prefix[ADDR_PREFIX])
> -    if ((val & ~(((addressT) 2 << 31) - 1)) == 0)
> -      val = (val ^ ((addressT) 1 << 31)) - ((addressT) 1 << 31);
> -#endif
> -

This code came from

commit 3e73aa7c956514ce5bd5fa6320fb239229ac8a7b
Author: Jan Hubicka <[hidden email]>
Date:   Wed Dec 20 13:24:13 2000 +0000

            * tc-i386.h (i386_target_format): Define even for ELFs.

My changes only enabled it when BFD64 is defined.  If this code
dead, please replace it with abort for now.

Thanks.

>    if ((val & ~mask) != 0 && (val & ~mask) != ~mask)
>      {
>        char buf1[40], buf2[40];



--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: offset_in_range() question

Jan Beulich-2
On 13.07.2020 15:11, H.J. Lu wrote:

> On Mon, Jul 13, 2020 at 5:50 AM Jan Beulich <[hidden email]> wrote:
>>
>> H.J.,
>>
>> the dependency on presence of an address size override, when the
>> function is also used on immediate operands, struck me as being
>> a possible source for problems. On 2009-09-15 you've made two
>> changes to the construct in question, but I wonder whether even
>> back then this code wasn't already dead. When, after quite a bit
>> of playing, I couldn't come up with any immediate that this
>> would go wrong on, I thought I'll give a try to removing that
>> code altogether. And indeed - no fallout. Looking more closely
>> then suggested that respective logic in optimize_imm() and
>> optimize_disp() are already arranging for values to never need
>> further massaging here.
>>
>> Do you agree that the code could be removed (see patch below in
>> case of any uncertainty about what block of code I mean), or are
>> you aware of things that might break this way?
>>
>> As an aside, I don't think the handling of out-of-range
>> immediates is quite correct, but I'll get to this in more detail
>> after thinking some more on possible solutions.
>>
>> Jan
>>
>> --- a/gas/config/tc-i386.c
>> +++ b/gas/config/tc-i386.c
>> @@ -2539,14 +2539,6 @@ offset_in_range (offsetT val, int size)
>>      default: abort ();
>>      }
>>
>> -#ifdef BFD64
>> -  /* If BFD64, sign extend val for 32bit address mode.  */
>> -  if (flag_code != CODE_64BIT
>> -      || i.prefix[ADDR_PREFIX])
>> -    if ((val & ~(((addressT) 2 << 31) - 1)) == 0)
>> -      val = (val ^ ((addressT) 1 << 31)) - ((addressT) 1 << 31);
>> -#endif
>> -
>
> This code came from
>
> commit 3e73aa7c956514ce5bd5fa6320fb239229ac8a7b
> Author: Jan Hubicka <[hidden email]>
> Date:   Wed Dec 20 13:24:13 2000 +0000
>
>             * tc-i386.h (i386_target_format): Define even for ELFs.
>
> My changes only enabled it when BFD64 is defined.  If this code
> dead, please replace it with abort for now.

I guess I don't understand: There's no condition to abort() on right
now. The code I'm proposing to delete simply does nothing useful. Or
do you mean to turn the assignment into an != to control when to
abort()?

Doing so would undermine the main purpose of deleting this code: Its
dependency on address prefix presence is what needs to go away.

Jan
Reply | Threaded
Open this post in threaded view
|

Re: offset_in_range() question

Sourceware - binutils list mailing list
On Mon, Jul 13, 2020 at 7:43 AM Jan Beulich <[hidden email]> wrote:

>
> On 13.07.2020 15:11, H.J. Lu wrote:
> > On Mon, Jul 13, 2020 at 5:50 AM Jan Beulich <[hidden email]> wrote:
> >>
> >> H.J.,
> >>
> >> the dependency on presence of an address size override, when the
> >> function is also used on immediate operands, struck me as being
> >> a possible source for problems. On 2009-09-15 you've made two
> >> changes to the construct in question, but I wonder whether even
> >> back then this code wasn't already dead. When, after quite a bit
> >> of playing, I couldn't come up with any immediate that this
> >> would go wrong on, I thought I'll give a try to removing that
> >> code altogether. And indeed - no fallout. Looking more closely
> >> then suggested that respective logic in optimize_imm() and
> >> optimize_disp() are already arranging for values to never need
> >> further massaging here.
> >>
> >> Do you agree that the code could be removed (see patch below in
> >> case of any uncertainty about what block of code I mean), or are
> >> you aware of things that might break this way?
> >>
> >> As an aside, I don't think the handling of out-of-range
> >> immediates is quite correct, but I'll get to this in more detail
> >> after thinking some more on possible solutions.
> >>
> >> Jan
> >>
> >> --- a/gas/config/tc-i386.c
> >> +++ b/gas/config/tc-i386.c
> >> @@ -2539,14 +2539,6 @@ offset_in_range (offsetT val, int size)
> >>      default: abort ();
> >>      }
> >>
> >> -#ifdef BFD64
> >> -  /* If BFD64, sign extend val for 32bit address mode.  */
> >> -  if (flag_code != CODE_64BIT
> >> -      || i.prefix[ADDR_PREFIX])
> >> -    if ((val & ~(((addressT) 2 << 31) - 1)) == 0)
> >> -      val = (val ^ ((addressT) 1 << 31)) - ((addressT) 1 << 31);
> >> -#endif
> >> -
> >
> > This code came from
> >
> > commit 3e73aa7c956514ce5bd5fa6320fb239229ac8a7b
> > Author: Jan Hubicka <[hidden email]>
> > Date:   Wed Dec 20 13:24:13 2000 +0000
> >
> >             * tc-i386.h (i386_target_format): Define even for ELFs.
> >
> > My changes only enabled it when BFD64 is defined.  If this code
> > dead, please replace it with abort for now.
>
> I guess I don't understand: There's no condition to abort() on right
> now. The code I'm proposing to delete simply does nothing useful. Or
> do you mean to turn the assignment into an != to control when to
> abort()?
>
> Doing so would undermine the main purpose of deleting this code: Its
> dependency on address prefix presence is what needs to go away.

I didn't add the code in question.  I only changed it to BFD64 only.
I don't know the history behind it.  If it is dead code, just change it
to

if (...)
  abort ();

We will keep it for a few months and then delete the whole thing.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: offset_in_range() question

Jan Beulich-2
On 13.07.2020 17:11, H.J. Lu wrote:

> On Mon, Jul 13, 2020 at 7:43 AM Jan Beulich <[hidden email]> wrote:
>>
>> On 13.07.2020 15:11, H.J. Lu wrote:
>>> On Mon, Jul 13, 2020 at 5:50 AM Jan Beulich <[hidden email]> wrote:
>>>>
>>>> H.J.,
>>>>
>>>> the dependency on presence of an address size override, when the
>>>> function is also used on immediate operands, struck me as being
>>>> a possible source for problems. On 2009-09-15 you've made two
>>>> changes to the construct in question, but I wonder whether even
>>>> back then this code wasn't already dead. When, after quite a bit
>>>> of playing, I couldn't come up with any immediate that this
>>>> would go wrong on, I thought I'll give a try to removing that
>>>> code altogether. And indeed - no fallout. Looking more closely
>>>> then suggested that respective logic in optimize_imm() and
>>>> optimize_disp() are already arranging for values to never need
>>>> further massaging here.
>>>>
>>>> Do you agree that the code could be removed (see patch below in
>>>> case of any uncertainty about what block of code I mean), or are
>>>> you aware of things that might break this way?
>>>>
>>>> As an aside, I don't think the handling of out-of-range
>>>> immediates is quite correct, but I'll get to this in more detail
>>>> after thinking some more on possible solutions.
>>>>
>>>> Jan
>>>>
>>>> --- a/gas/config/tc-i386.c
>>>> +++ b/gas/config/tc-i386.c
>>>> @@ -2539,14 +2539,6 @@ offset_in_range (offsetT val, int size)
>>>>      default: abort ();
>>>>      }
>>>>
>>>> -#ifdef BFD64
>>>> -  /* If BFD64, sign extend val for 32bit address mode.  */
>>>> -  if (flag_code != CODE_64BIT
>>>> -      || i.prefix[ADDR_PREFIX])
>>>> -    if ((val & ~(((addressT) 2 << 31) - 1)) == 0)
>>>> -      val = (val ^ ((addressT) 1 << 31)) - ((addressT) 1 << 31);
>>>> -#endif
>>>> -
>>>
>>> This code came from
>>>
>>> commit 3e73aa7c956514ce5bd5fa6320fb239229ac8a7b
>>> Author: Jan Hubicka <[hidden email]>
>>> Date:   Wed Dec 20 13:24:13 2000 +0000
>>>
>>>             * tc-i386.h (i386_target_format): Define even for ELFs.
>>>
>>> My changes only enabled it when BFD64 is defined.  If this code
>>> dead, please replace it with abort for now.
>>
>> I guess I don't understand: There's no condition to abort() on right
>> now. The code I'm proposing to delete simply does nothing useful. Or
>> do you mean to turn the assignment into an != to control when to
>> abort()?
>>
>> Doing so would undermine the main purpose of deleting this code: Its
>> dependency on address prefix presence is what needs to go away.
>
> I didn't add the code in question.  I only changed it to BFD64 only.

You didn't add the sign extension, true, but the thing that caught my
eye here is the use of i.prefix[ADDR_PREFIX], which you added in
9de868bf63da. And that's what should go away one way or another.
Initially I thought the caller may need to pass in whether we're
processing a displacement (where the address override matters) vs an
immediate (where it doesn't matter), until I figured the code is not
doing anything useful at all.

> I don't know the history behind it.  If it is dead code, just change it
> to
>
> if (...)
>   abort ();

Again - what's to go inside the if() should not have any undue use
of i.prefix[ADDR_PREFIX], so I'm afraid I still don't follow what
exactly you want me to put there.

Jan
Reply | Threaded
Open this post in threaded view
|

[PATCH] x86: Remove 32-bit sign extension in offset_in_range

Sourceware - binutils list mailing list
On Mon, Jul 13, 2020 at 8:40 AM Jan Beulich <[hidden email]> wrote:

>
> On 13.07.2020 17:11, H.J. Lu wrote:
> > On Mon, Jul 13, 2020 at 7:43 AM Jan Beulich <[hidden email]> wrote:
> >>
> >> On 13.07.2020 15:11, H.J. Lu wrote:
> >>> On Mon, Jul 13, 2020 at 5:50 AM Jan Beulich <[hidden email]> wrote:
> >>>>
> >>>> H.J.,
> >>>>
> >>>> the dependency on presence of an address size override, when the
> >>>> function is also used on immediate operands, struck me as being
> >>>> a possible source for problems. On 2009-09-15 you've made two
> >>>> changes to the construct in question, but I wonder whether even
> >>>> back then this code wasn't already dead. When, after quite a bit
> >>>> of playing, I couldn't come up with any immediate that this
> >>>> would go wrong on, I thought I'll give a try to removing that
> >>>> code altogether. And indeed - no fallout. Looking more closely
> >>>> then suggested that respective logic in optimize_imm() and
> >>>> optimize_disp() are already arranging for values to never need
> >>>> further massaging here.
> >>>>
> >>>> Do you agree that the code could be removed (see patch below in
> >>>> case of any uncertainty about what block of code I mean), or are
> >>>> you aware of things that might break this way?
> >>>>
> >>>> As an aside, I don't think the handling of out-of-range
> >>>> immediates is quite correct, but I'll get to this in more detail
> >>>> after thinking some more on possible solutions.
> >>>>
> >>>> Jan
> >>>>
> >>>> --- a/gas/config/tc-i386.c
> >>>> +++ b/gas/config/tc-i386.c
> >>>> @@ -2539,14 +2539,6 @@ offset_in_range (offsetT val, int size)
> >>>>      default: abort ();
> >>>>      }
> >>>>
> >>>> -#ifdef BFD64
> >>>> -  /* If BFD64, sign extend val for 32bit address mode.  */
> >>>> -  if (flag_code != CODE_64BIT
> >>>> -      || i.prefix[ADDR_PREFIX])
> >>>> -    if ((val & ~(((addressT) 2 << 31) - 1)) == 0)
> >>>> -      val = (val ^ ((addressT) 1 << 31)) - ((addressT) 1 << 31);
> >>>> -#endif
> >>>> -
> >>>
> >>> This code came from
> >>>
> >>> commit 3e73aa7c956514ce5bd5fa6320fb239229ac8a7b
> >>> Author: Jan Hubicka <[hidden email]>
> >>> Date:   Wed Dec 20 13:24:13 2000 +0000
> >>>
> >>>             * tc-i386.h (i386_target_format): Define even for ELFs.
> >>>
> >>> My changes only enabled it when BFD64 is defined.  If this code
> >>> dead, please replace it with abort for now.
> >>
> >> I guess I don't understand: There's no condition to abort() on right
> >> now. The code I'm proposing to delete simply does nothing useful. Or
> >> do you mean to turn the assignment into an != to control when to
> >> abort()?
> >>
> >> Doing so would undermine the main purpose of deleting this code: Its
> >> dependency on address prefix presence is what needs to go away.
> >
> > I didn't add the code in question.  I only changed it to BFD64 only.
>
> You didn't add the sign extension, true, but the thing that caught my
> eye here is the use of i.prefix[ADDR_PREFIX], which you added in
> 9de868bf63da. And that's what should go away one way or another.
> Initially I thought the caller may need to pass in whether we're
> processing a displacement (where the address override matters) vs an
> immediate (where it doesn't matter), until I figured the code is not
> doing anything useful at all.
>
> > I don't know the history behind it.  If it is dead code, just change it
> > to
> >
> > if (...)
> >   abort ();
>
> Again - what's to go inside the if() should not have any undue use
> of i.prefix[ADDR_PREFIX], so I'm afraid I still don't follow what
> exactly you want me to put there.
>
I am checking in this.

--
H.J.

0001-x86-Remove-32-bit-sign-extension-in-offset_in_range.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86: Remove 32-bit sign extension in offset_in_range

Jan Beulich-2
On 13.07.2020 19:23, H.J. Lu wrote:

> On Mon, Jul 13, 2020 at 8:40 AM Jan Beulich <[hidden email]> wrote:
>>
>> On 13.07.2020 17:11, H.J. Lu wrote:
>>> On Mon, Jul 13, 2020 at 7:43 AM Jan Beulich <[hidden email]> wrote:
>>>>
>>>> On 13.07.2020 15:11, H.J. Lu wrote:
>>>>> On Mon, Jul 13, 2020 at 5:50 AM Jan Beulich <[hidden email]> wrote:
>>>>>>
>>>>>> H.J.,
>>>>>>
>>>>>> the dependency on presence of an address size override, when the
>>>>>> function is also used on immediate operands, struck me as being
>>>>>> a possible source for problems. On 2009-09-15 you've made two
>>>>>> changes to the construct in question, but I wonder whether even
>>>>>> back then this code wasn't already dead. When, after quite a bit
>>>>>> of playing, I couldn't come up with any immediate that this
>>>>>> would go wrong on, I thought I'll give a try to removing that
>>>>>> code altogether. And indeed - no fallout. Looking more closely
>>>>>> then suggested that respective logic in optimize_imm() and
>>>>>> optimize_disp() are already arranging for values to never need
>>>>>> further massaging here.
>>>>>>
>>>>>> Do you agree that the code could be removed (see patch below in
>>>>>> case of any uncertainty about what block of code I mean), or are
>>>>>> you aware of things that might break this way?
>>>>>>
>>>>>> As an aside, I don't think the handling of out-of-range
>>>>>> immediates is quite correct, but I'll get to this in more detail
>>>>>> after thinking some more on possible solutions.
>>>>>>
>>>>>> Jan
>>>>>>
>>>>>> --- a/gas/config/tc-i386.c
>>>>>> +++ b/gas/config/tc-i386.c
>>>>>> @@ -2539,14 +2539,6 @@ offset_in_range (offsetT val, int size)
>>>>>>      default: abort ();
>>>>>>      }
>>>>>>
>>>>>> -#ifdef BFD64
>>>>>> -  /* If BFD64, sign extend val for 32bit address mode.  */
>>>>>> -  if (flag_code != CODE_64BIT
>>>>>> -      || i.prefix[ADDR_PREFIX])
>>>>>> -    if ((val & ~(((addressT) 2 << 31) - 1)) == 0)
>>>>>> -      val = (val ^ ((addressT) 1 << 31)) - ((addressT) 1 << 31);
>>>>>> -#endif
>>>>>> -
>>>>>
>>>>> This code came from
>>>>>
>>>>> commit 3e73aa7c956514ce5bd5fa6320fb239229ac8a7b
>>>>> Author: Jan Hubicka <[hidden email]>
>>>>> Date:   Wed Dec 20 13:24:13 2000 +0000
>>>>>
>>>>>             * tc-i386.h (i386_target_format): Define even for ELFs.
>>>>>
>>>>> My changes only enabled it when BFD64 is defined.  If this code
>>>>> dead, please replace it with abort for now.
>>>>
>>>> I guess I don't understand: There's no condition to abort() on right
>>>> now. The code I'm proposing to delete simply does nothing useful. Or
>>>> do you mean to turn the assignment into an != to control when to
>>>> abort()?
>>>>
>>>> Doing so would undermine the main purpose of deleting this code: Its
>>>> dependency on address prefix presence is what needs to go away.
>>>
>>> I didn't add the code in question.  I only changed it to BFD64 only.
>>
>> You didn't add the sign extension, true, but the thing that caught my
>> eye here is the use of i.prefix[ADDR_PREFIX], which you added in
>> 9de868bf63da. And that's what should go away one way or another.
>> Initially I thought the caller may need to pass in whether we're
>> processing a displacement (where the address override matters) vs an
>> immediate (where it doesn't matter), until I figured the code is not
>> doing anything useful at all.
>>
>>> I don't know the history behind it.  If it is dead code, just change it
>>> to
>>>
>>> if (...)
>>>   abort ();
>>
>> Again - what's to go inside the if() should not have any undue use
>> of i.prefix[ADDR_PREFIX], so I'm afraid I still don't follow what
>> exactly you want me to put there.
>>
>
> I am checking in this.

So that's exactly what I proposed, but with, I'm afraid, a misleading
description: While the sign extension indeed is unnecessary for
encoding (and for 32-bit addresses it really is wrong, as addresses
get zero-extended), it is my understanding that the logic was thought
to be necessary for the subsequent conditional around the warning to
yield false. I'm meanwhile wondering whether something breaks this
way with 16-bit addressing.

Nevertheless, I've meanwhile thought of a (contrived) case that was
broken with the code present:

        addr32 mov $0x89abcdef, %rax

would have got the immediate sign-extended from 32 to 64 bits.

Jan
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86: Remove 32-bit sign extension in offset_in_range

Sourceware - binutils list mailing list
On Mon, Jul 13, 2020 at 11:12 PM Jan Beulich <[hidden email]> wrote:

>
> On 13.07.2020 19:23, H.J. Lu wrote:
> > On Mon, Jul 13, 2020 at 8:40 AM Jan Beulich <[hidden email]> wrote:
> >>
> >> On 13.07.2020 17:11, H.J. Lu wrote:
> >>> On Mon, Jul 13, 2020 at 7:43 AM Jan Beulich <[hidden email]> wrote:
> >>>>
> >>>> On 13.07.2020 15:11, H.J. Lu wrote:
> >>>>> On Mon, Jul 13, 2020 at 5:50 AM Jan Beulich <[hidden email]> wrote:
> >>>>>>
> >>>>>> H.J.,
> >>>>>>
> >>>>>> the dependency on presence of an address size override, when the
> >>>>>> function is also used on immediate operands, struck me as being
> >>>>>> a possible source for problems. On 2009-09-15 you've made two
> >>>>>> changes to the construct in question, but I wonder whether even
> >>>>>> back then this code wasn't already dead. When, after quite a bit
> >>>>>> of playing, I couldn't come up with any immediate that this
> >>>>>> would go wrong on, I thought I'll give a try to removing that
> >>>>>> code altogether. And indeed - no fallout. Looking more closely
> >>>>>> then suggested that respective logic in optimize_imm() and
> >>>>>> optimize_disp() are already arranging for values to never need
> >>>>>> further massaging here.
> >>>>>>
> >>>>>> Do you agree that the code could be removed (see patch below in
> >>>>>> case of any uncertainty about what block of code I mean), or are
> >>>>>> you aware of things that might break this way?
> >>>>>>
> >>>>>> As an aside, I don't think the handling of out-of-range
> >>>>>> immediates is quite correct, but I'll get to this in more detail
> >>>>>> after thinking some more on possible solutions.
> >>>>>>
> >>>>>> Jan
> >>>>>>
> >>>>>> --- a/gas/config/tc-i386.c
> >>>>>> +++ b/gas/config/tc-i386.c
> >>>>>> @@ -2539,14 +2539,6 @@ offset_in_range (offsetT val, int size)
> >>>>>>      default: abort ();
> >>>>>>      }
> >>>>>>
> >>>>>> -#ifdef BFD64
> >>>>>> -  /* If BFD64, sign extend val for 32bit address mode.  */
> >>>>>> -  if (flag_code != CODE_64BIT
> >>>>>> -      || i.prefix[ADDR_PREFIX])
> >>>>>> -    if ((val & ~(((addressT) 2 << 31) - 1)) == 0)
> >>>>>> -      val = (val ^ ((addressT) 1 << 31)) - ((addressT) 1 << 31);
> >>>>>> -#endif
> >>>>>> -
> >>>>>
> >>>>> This code came from
> >>>>>
> >>>>> commit 3e73aa7c956514ce5bd5fa6320fb239229ac8a7b
> >>>>> Author: Jan Hubicka <[hidden email]>
> >>>>> Date:   Wed Dec 20 13:24:13 2000 +0000
> >>>>>
> >>>>>             * tc-i386.h (i386_target_format): Define even for ELFs.
> >>>>>
> >>>>> My changes only enabled it when BFD64 is defined.  If this code
> >>>>> dead, please replace it with abort for now.
> >>>>
> >>>> I guess I don't understand: There's no condition to abort() on right
> >>>> now. The code I'm proposing to delete simply does nothing useful. Or
> >>>> do you mean to turn the assignment into an != to control when to
> >>>> abort()?
> >>>>
> >>>> Doing so would undermine the main purpose of deleting this code: Its
> >>>> dependency on address prefix presence is what needs to go away.
> >>>
> >>> I didn't add the code in question.  I only changed it to BFD64 only.
> >>
> >> You didn't add the sign extension, true, but the thing that caught my
> >> eye here is the use of i.prefix[ADDR_PREFIX], which you added in
> >> 9de868bf63da. And that's what should go away one way or another.
> >> Initially I thought the caller may need to pass in whether we're
> >> processing a displacement (where the address override matters) vs an
> >> immediate (where it doesn't matter), until I figured the code is not
> >> doing anything useful at all.
> >>
> >>> I don't know the history behind it.  If it is dead code, just change it
> >>> to
> >>>
> >>> if (...)
> >>>   abort ();
> >>
> >> Again - what's to go inside the if() should not have any undue use
> >> of i.prefix[ADDR_PREFIX], so I'm afraid I still don't follow what
> >> exactly you want me to put there.
> >>
> >
> > I am checking in this.
>
> So that's exactly what I proposed, but with, I'm afraid, a misleading
> description: While the sign extension indeed is unnecessary for
> encoding (and for 32-bit addresses it really is wrong, as addresses
> get zero-extended), it is my understanding that the logic was thought
> to be necessary for the subsequent conditional around the warning to
> yield false. I'm meanwhile wondering whether something breaks this
> way with 16-bit addressing.
>
> Nevertheless, I've meanwhile thought of a (contrived) case that was
> broken with the code present:
>
>         addr32 mov $0x89abcdef, %rax
>
> would have got the immediate sign-extended from 32 to 64 bits.
>

I opened:

https://sourceware.org/bugzilla/show_bug.cgi?id=26237

There are multiple issues.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86: Remove 32-bit sign extension in offset_in_range

Jan Beulich-2
On 14.07.2020 14:43, H.J. Lu wrote:

> On Mon, Jul 13, 2020 at 11:12 PM Jan Beulich <[hidden email]> wrote:
>> Nevertheless, I've meanwhile thought of a (contrived) case that was
>> broken with the code present:
>>
>>         addr32 mov $0x89abcdef, %rax
>>
>> would have got the immediate sign-extended from 32 to 64 bits.
>>
>
> I opened:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=26237
>
> There are multiple issues.

Hmm, the former two lines there look correct to me, while the latter
two lines look to have been translated with a gas that didn't have
yesterday's change yet. IOW - I'm somewhat confused.

Jan
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86: Remove 32-bit sign extension in offset_in_range

Sourceware - binutils list mailing list
On Tue, Jul 14, 2020 at 5:51 AM Jan Beulich <[hidden email]> wrote:

>
> On 14.07.2020 14:43, H.J. Lu wrote:
> > On Mon, Jul 13, 2020 at 11:12 PM Jan Beulich <[hidden email]> wrote:
> >> Nevertheless, I've meanwhile thought of a (contrived) case that was
> >> broken with the code present:
> >>
> >>         addr32 mov $0x89abcdef, %rax
> >>
> >> would have got the immediate sign-extended from 32 to 64 bits.
> >>
> >
> > I opened:
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=26237
> >
> > There are multiple issues.
>
> Hmm, the former two lines there look correct to me, while the latter
> two lines look to have been translated with a gas that didn't have
> yesterday's change yet. IOW - I'm somewhat confused.

The bug is against binutils 2.35, not master.


--
H.J.
Reply | Threaded
Open this post in threaded view
|

[PATCH] x86-64: Zero-extend lower 32 bits displacement to 64 bits

Sourceware - binutils list mailing list
On Tue, Jul 14, 2020 at 5:55 AM H.J. Lu <[hidden email]> wrote:

>
> On Tue, Jul 14, 2020 at 5:51 AM Jan Beulich <[hidden email]> wrote:
> >
> > On 14.07.2020 14:43, H.J. Lu wrote:
> > > On Mon, Jul 13, 2020 at 11:12 PM Jan Beulich <[hidden email]> wrote:
> > >> Nevertheless, I've meanwhile thought of a (contrived) case that was
> > >> broken with the code present:
> > >>
> > >>         addr32 mov $0x89abcdef, %rax
> > >>
> > >> would have got the immediate sign-extended from 32 to 64 bits.
> > >>
> > >
> > > I opened:
> > >
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=26237
> > >
> > > There are multiple issues.
> >
> > Hmm, the former two lines there look correct to me, while the latter
> > two lines look to have been translated with a gas that didn't have
> > yesterday's change yet. IOW - I'm somewhat confused.
>
> The bug is against binutils 2.35, not master.
>
Here is the patch for master branch.  I will backport it to 2.35 branch
together with

https://sourceware.org/pipermail/binutils/2020-July/112356.html


--
H.J.

0001-x86-64-Zero-extend-lower-32-bits-displacement-to-64-.patch (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86-64: Zero-extend lower 32 bits displacement to 64 bits

Jan Beulich-2
On 14.07.2020 18:54, H.J. Lu wrote:

> On Tue, Jul 14, 2020 at 5:55 AM H.J. Lu <[hidden email]> wrote:
>>
>> On Tue, Jul 14, 2020 at 5:51 AM Jan Beulich <[hidden email]> wrote:
>>>
>>> On 14.07.2020 14:43, H.J. Lu wrote:
>>>> On Mon, Jul 13, 2020 at 11:12 PM Jan Beulich <[hidden email]> wrote:
>>>>> Nevertheless, I've meanwhile thought of a (contrived) case that was
>>>>> broken with the code present:
>>>>>
>>>>>         addr32 mov $0x89abcdef, %rax
>>>>>
>>>>> would have got the immediate sign-extended from 32 to 64 bits.
>>>>>
>>>>
>>>> I opened:
>>>>
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=26237
>>>>
>>>> There are multiple issues.
>>>
>>> Hmm, the former two lines there look correct to me, while the latter
>>> two lines look to have been translated with a gas that didn't have
>>> yesterday's change yet. IOW - I'm somewhat confused.
>>
>> The bug is against binutils 2.35, not master.
>>
>
> Here is the patch for master branch.

Ah, so your issue was just with disassembly. Yet then why not go a step
further and (at least in 64-bit mode) print

[ ]*[a-f0-9]+: 67 48 89 1c 25 ef cd ab 89 mov[ ]+%rbx,0x89abcdef
[ ]*[a-f0-9]+: 67 89 04 25 11 22 33 ff mov[ ]+%eax,0xff332211

instead of

[ ]*[a-f0-9]+: 67 48 89 1c 25 ef cd ab 89 mov[ ]+%rbx,0x89abcdef\(,%eiz,1\)
[ ]*[a-f0-9]+: 67 89 04 25 11 22 33 ff mov[ ]+%eax,0xff332211\(,%eiz,1\)

and keep the () part only for

[ ]*[a-f0-9]+: 67 89 04 65 11 22 33 ff mov[ ]+%eax,0xff332211\(,%eiz,2\)

, as there's no SIB-less way to express a base-and-index-less address?

Jan
Reply | Threaded
Open this post in threaded view
|

[PATCH] x86: Don't display eiz with no scale

Sourceware - binutils list mailing list
On Tue, Jul 14, 2020 at 11:14 PM Jan Beulich <[hidden email]> wrote:

>
> On 14.07.2020 18:54, H.J. Lu wrote:
> > On Tue, Jul 14, 2020 at 5:55 AM H.J. Lu <[hidden email]> wrote:
> >>
> >> On Tue, Jul 14, 2020 at 5:51 AM Jan Beulich <[hidden email]> wrote:
> >>>
> >>> On 14.07.2020 14:43, H.J. Lu wrote:
> >>>> On Mon, Jul 13, 2020 at 11:12 PM Jan Beulich <[hidden email]> wrote:
> >>>>> Nevertheless, I've meanwhile thought of a (contrived) case that was
> >>>>> broken with the code present:
> >>>>>
> >>>>>         addr32 mov $0x89abcdef, %rax
> >>>>>
> >>>>> would have got the immediate sign-extended from 32 to 64 bits.
> >>>>>
> >>>>
> >>>> I opened:
> >>>>
> >>>> https://sourceware.org/bugzilla/show_bug.cgi?id=26237
> >>>>
> >>>> There are multiple issues.
> >>>
> >>> Hmm, the former two lines there look correct to me, while the latter
> >>> two lines look to have been translated with a gas that didn't have
> >>> yesterday's change yet. IOW - I'm somewhat confused.
> >>
> >> The bug is against binutils 2.35, not master.
> >>
> >
> > Here is the patch for master branch.
>
> Ah, so your issue was just with disassembly. Yet then why not go a step
> further and (at least in 64-bit mode) print
>
> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef
> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211
>
> instead of
>
> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef\(,%eiz,1\)
> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,1\)
>
> and keep the () part only for
>
> [       ]*[a-f0-9]+:    67 89 04 65 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,2\)
>
> , as there's no SIB-less way to express a base-and-index-less address?
>
Done.

I am checking in this.

--
H.J.

0001-x86-Don-t-display-eiz-with-no-scale.patch (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86: Don't display eiz with no scale

Jan Beulich-2
On 15.07.2020 15:57, H.J. Lu wrote:

> On Tue, Jul 14, 2020 at 11:14 PM Jan Beulich <[hidden email]> wrote:
>>
>> On 14.07.2020 18:54, H.J. Lu wrote:
>>> On Tue, Jul 14, 2020 at 5:55 AM H.J. Lu <[hidden email]> wrote:
>>>>
>>>> On Tue, Jul 14, 2020 at 5:51 AM Jan Beulich <[hidden email]> wrote:
>>>>>
>>>>> On 14.07.2020 14:43, H.J. Lu wrote:
>>>>>> On Mon, Jul 13, 2020 at 11:12 PM Jan Beulich <[hidden email]> wrote:
>>>>>>> Nevertheless, I've meanwhile thought of a (contrived) case that was
>>>>>>> broken with the code present:
>>>>>>>
>>>>>>>         addr32 mov $0x89abcdef, %rax
>>>>>>>
>>>>>>> would have got the immediate sign-extended from 32 to 64 bits.
>>>>>>>
>>>>>>
>>>>>> I opened:
>>>>>>
>>>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=26237
>>>>>>
>>>>>> There are multiple issues.
>>>>>
>>>>> Hmm, the former two lines there look correct to me, while the latter
>>>>> two lines look to have been translated with a gas that didn't have
>>>>> yesterday's change yet. IOW - I'm somewhat confused.
>>>>
>>>> The bug is against binutils 2.35, not master.
>>>>
>>>
>>> Here is the patch for master branch.
>>
>> Ah, so your issue was just with disassembly. Yet then why not go a step
>> further and (at least in 64-bit mode) print
>>
>> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef
>> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211
>>
>> instead of
>>
>> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef\(,%eiz,1\)
>> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,1\)
>>
>> and keep the () part only for
>>
>> [       ]*[a-f0-9]+:    67 89 04 65 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,2\)
>>
>> , as there's no SIB-less way to express a base-and-index-less address?
>>
>
> Done.
>
> I am checking in this.

Having only now noticed the collision with my change to
evex-no-scale-64.d, I wonder whether we want to revert your change,
and hence whether my underlying suggestion was a bad one: There's
now no sign left that these insns use 32-bit address mode. The
alternative would be to ensure that an addr32 prefix gets emitted.
I'd personally favor this alternative, but I could live with the
revert. (When making the suggestion I didn't realize this is a
32-bit-addressing-specific output mode.)

Jan
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86: Don't display eiz with no scale

Sourceware - binutils list mailing list
On Tue, Jul 21, 2020 at 2:40 AM Jan Beulich <[hidden email]> wrote:

>
> On 15.07.2020 15:57, H.J. Lu wrote:
> > On Tue, Jul 14, 2020 at 11:14 PM Jan Beulich <[hidden email]> wrote:
> >>
> >> On 14.07.2020 18:54, H.J. Lu wrote:
> >>> On Tue, Jul 14, 2020 at 5:55 AM H.J. Lu <[hidden email]> wrote:
> >>>>
> >>>> On Tue, Jul 14, 2020 at 5:51 AM Jan Beulich <[hidden email]> wrote:
> >>>>>
> >>>>> On 14.07.2020 14:43, H.J. Lu wrote:
> >>>>>> On Mon, Jul 13, 2020 at 11:12 PM Jan Beulich <[hidden email]> wrote:
> >>>>>>> Nevertheless, I've meanwhile thought of a (contrived) case that was
> >>>>>>> broken with the code present:
> >>>>>>>
> >>>>>>>         addr32 mov $0x89abcdef, %rax
> >>>>>>>
> >>>>>>> would have got the immediate sign-extended from 32 to 64 bits.
> >>>>>>>
> >>>>>>
> >>>>>> I opened:
> >>>>>>
> >>>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=26237
> >>>>>>
> >>>>>> There are multiple issues.
> >>>>>
> >>>>> Hmm, the former two lines there look correct to me, while the latter
> >>>>> two lines look to have been translated with a gas that didn't have
> >>>>> yesterday's change yet. IOW - I'm somewhat confused.
> >>>>
> >>>> The bug is against binutils 2.35, not master.
> >>>>
> >>>
> >>> Here is the patch for master branch.
> >>
> >> Ah, so your issue was just with disassembly. Yet then why not go a step
> >> further and (at least in 64-bit mode) print
> >>
> >> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef
> >> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211
> >>
> >> instead of
> >>
> >> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef\(,%eiz,1\)
> >> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,1\)
> >>
> >> and keep the () part only for
> >>
> >> [       ]*[a-f0-9]+:    67 89 04 65 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,2\)
> >>
> >> , as there's no SIB-less way to express a base-and-index-less address?
> >>
> >
> > Done.
> >
> > I am checking in this.
>
> Having only now noticed the collision with my change to
> evex-no-scale-64.d, I wonder whether we want to revert your change,
> and hence whether my underlying suggestion was a bad one: There's
> now no sign left that these insns use 32-bit address mode. The
> alternative would be to ensure that an addr32 prefix gets emitted.
> I'd personally favor this alternative, but I could live with the
> revert. (When making the suggestion I didn't realize this is a
> 32-bit-addressing-specific output mode.)
>

Can you revert it for me?

Thanks.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86: Don't display eiz with no scale

Jan Beulich-2
On 21.07.2020 13:29, H.J. Lu wrote:

> On Tue, Jul 21, 2020 at 2:40 AM Jan Beulich <[hidden email]> wrote:
>>
>> On 15.07.2020 15:57, H.J. Lu wrote:
>>> On Tue, Jul 14, 2020 at 11:14 PM Jan Beulich <[hidden email]> wrote:
>>>>
>>>> On 14.07.2020 18:54, H.J. Lu wrote:
>>>>> On Tue, Jul 14, 2020 at 5:55 AM H.J. Lu <[hidden email]> wrote:
>>>>>>
>>>>>> On Tue, Jul 14, 2020 at 5:51 AM Jan Beulich <[hidden email]> wrote:
>>>>>>>
>>>>>>> On 14.07.2020 14:43, H.J. Lu wrote:
>>>>>>>> On Mon, Jul 13, 2020 at 11:12 PM Jan Beulich <[hidden email]> wrote:
>>>>>>>>> Nevertheless, I've meanwhile thought of a (contrived) case that was
>>>>>>>>> broken with the code present:
>>>>>>>>>
>>>>>>>>>         addr32 mov $0x89abcdef, %rax
>>>>>>>>>
>>>>>>>>> would have got the immediate sign-extended from 32 to 64 bits.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I opened:
>>>>>>>>
>>>>>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=26237
>>>>>>>>
>>>>>>>> There are multiple issues.
>>>>>>>
>>>>>>> Hmm, the former two lines there look correct to me, while the latter
>>>>>>> two lines look to have been translated with a gas that didn't have
>>>>>>> yesterday's change yet. IOW - I'm somewhat confused.
>>>>>>
>>>>>> The bug is against binutils 2.35, not master.
>>>>>>
>>>>>
>>>>> Here is the patch for master branch.
>>>>
>>>> Ah, so your issue was just with disassembly. Yet then why not go a step
>>>> further and (at least in 64-bit mode) print
>>>>
>>>> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef
>>>> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211
>>>>
>>>> instead of
>>>>
>>>> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef\(,%eiz,1\)
>>>> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,1\)
>>>>
>>>> and keep the () part only for
>>>>
>>>> [       ]*[a-f0-9]+:    67 89 04 65 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,2\)
>>>>
>>>> , as there's no SIB-less way to express a base-and-index-less address?
>>>>
>>>
>>> Done.
>>>
>>> I am checking in this.
>>
>> Having only now noticed the collision with my change to
>> evex-no-scale-64.d, I wonder whether we want to revert your change,
>> and hence whether my underlying suggestion was a bad one: There's
>> now no sign left that these insns use 32-bit address mode. The
>> alternative would be to ensure that an addr32 prefix gets emitted.
>> I'd personally favor this alternative, but I could live with the
>> revert. (When making the suggestion I didn't realize this is a
>> 32-bit-addressing-specific output mode.)
>>
>
> Can you revert it for me?

Done.

Jan
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] x86: Don't display eiz with no scale

Sourceware - binutils list mailing list
On Tue, Jul 21, 2020 at 5:22 AM Jan Beulich <[hidden email]> wrote:

>
> On 21.07.2020 13:29, H.J. Lu wrote:
> > On Tue, Jul 21, 2020 at 2:40 AM Jan Beulich <[hidden email]> wrote:
> >>
> >> On 15.07.2020 15:57, H.J. Lu wrote:
> >>> On Tue, Jul 14, 2020 at 11:14 PM Jan Beulich <[hidden email]> wrote:
> >>>>
> >>>> On 14.07.2020 18:54, H.J. Lu wrote:
> >>>>> On Tue, Jul 14, 2020 at 5:55 AM H.J. Lu <[hidden email]> wrote:
> >>>>>>
> >>>>>> On Tue, Jul 14, 2020 at 5:51 AM Jan Beulich <[hidden email]> wrote:
> >>>>>>>
> >>>>>>> On 14.07.2020 14:43, H.J. Lu wrote:
> >>>>>>>> On Mon, Jul 13, 2020 at 11:12 PM Jan Beulich <[hidden email]> wrote:
> >>>>>>>>> Nevertheless, I've meanwhile thought of a (contrived) case that was
> >>>>>>>>> broken with the code present:
> >>>>>>>>>
> >>>>>>>>>         addr32 mov $0x89abcdef, %rax
> >>>>>>>>>
> >>>>>>>>> would have got the immediate sign-extended from 32 to 64 bits.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I opened:
> >>>>>>>>
> >>>>>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=26237
> >>>>>>>>
> >>>>>>>> There are multiple issues.
> >>>>>>>
> >>>>>>> Hmm, the former two lines there look correct to me, while the latter
> >>>>>>> two lines look to have been translated with a gas that didn't have
> >>>>>>> yesterday's change yet. IOW - I'm somewhat confused.
> >>>>>>
> >>>>>> The bug is against binutils 2.35, not master.
> >>>>>>
> >>>>>
> >>>>> Here is the patch for master branch.
> >>>>
> >>>> Ah, so your issue was just with disassembly. Yet then why not go a step
> >>>> further and (at least in 64-bit mode) print
> >>>>
> >>>> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef
> >>>> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211
> >>>>
> >>>> instead of
> >>>>
> >>>> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef\(,%eiz,1\)
> >>>> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,1\)
> >>>>
> >>>> and keep the () part only for
> >>>>
> >>>> [       ]*[a-f0-9]+:    67 89 04 65 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,2\)
> >>>>
> >>>> , as there's no SIB-less way to express a base-and-index-less address?
> >>>>
> >>>
> >>> Done.
> >>>
> >>> I am checking in this.
> >>
> >> Having only now noticed the collision with my change to
> >> evex-no-scale-64.d, I wonder whether we want to revert your change,
> >> and hence whether my underlying suggestion was a bad one: There's
> >> now no sign left that these insns use 32-bit address mode. The
> >> alternative would be to ensure that an addr32 prefix gets emitted.
> >> I'd personally favor this alternative, but I could live with the
> >> revert. (When making the suggestion I didn't realize this is a
> >> 32-bit-addressing-specific output mode.)
> >>
> >
> > Can you revert it for me?
>
> Done.

Thanks.

--
H.J.