New .nops directive, to aid Linux alternatives patching?

[H.J. Lu]

On Sun, Feb 11, 2018 at 8:25 AM, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> On 11/02/2018 00:59, H.J. Lu wrote:
>>>> Please try users/hjl/nop branch:
>>>>
>>>> https://github.com/hjl-tools/binutils-gdb/tree/users/hjl/nop
>>> Oh - thankyou!  I was about to ask if there were any pointers to get
>>> started hacking on binutils.
>>>
>>> As for the functionality, there are unfortunately some issues.  Given
>>> this source:
>>>
>>>         .text
>>> single:
>>>         nop
>>>
>>> pseudo_1:
>>>         .nop 1
>>>
>>> pseudo_8:
>>>         .nop 8
>>>
>>> pseudo_8_4:
>>>         .nop 8, 4
>>>
>>> pseudo_20:
>>>         .nop 20
>>>
>>> I get the following disassembly:
>>>
>>> 0000000000000000 <single>:
>>>    0:    90                       nop
>>>
>>> 0000000000000001 <pseudo_1>:
>>>    1:    66 90                    xchg   %ax,%ax
>>>
>>> 0000000000000003 <pseudo_8>:
>>>    3:    66 0f 1f 84 00 00 00     nopw   0x0(%rax,%rax,1)
>>>    a:    00 00
>>>
>>> 000000000000000c <pseudo_8_4>:
>>>    c:    90                       nop
>>>    d:    0f 1f 40 00              nopl   0x0(%rax)
>>>   11:    0f 1f 40 00              nopl   0x0(%rax)
>>>
>>> 0000000000000015 <pseudo_20>:
>>>   15:    90                       nop
>>>   16:    66 2e 0f 1f 84 00 00     nopw   %cs:0x0(%rax,%rax,1)
>>>   1d:    00 00 00
>>>   20:    66 2e 0f 1f 84 00 00     nopw   %cs:0x0(%rax,%rax,1)
>>>   27:    00 00 00
>>>
>>> The MAX_NOP part looks to be working as intended (including reducing
>>> below the default of 10), but there appears to be an off-by-one
>>> somewhere, as one too many nops are emitted in the block.
>>>
>>> Furthermore, attempting to use .nop 30 yields:
>>>
>>> /tmp/ccI2Eakp.s: Assembler messages:
>>> /tmp/ccI2Eakp.s: Fatal error: can't write 145268933551616 bytes to
>>> section .text of nops.o: 'Bad value'
>> Please try my branch again.  It should be fixed.
>
> Thanks.  All of that looks to be in order.
>
> However, when trying to build larger examples, I've started hitting:
>
> /tmp/ccvxOy2v.s: Assembler messages:
> /tmp/ccvxOy2v.s: Internal error in md_convert_frag at
> ../../gas/config/tc-i386.c:9510.
>
> Which is the gas_assert (fragP->fr_var != BFD_RELOC_X86_NOP); you've added.
>
> It occurs when the calculation of the number of nops to insert evaluates
> to 0, and a simple ".nop 0" managed to reproduce the issue.  The
> calculation evaluating to 0 is a side effect of the existing logic to
> evaluate how much, if an, padding is required, and follows this kind of
> pattern:
>

It should be fixed now.  I also added 11-byte nop for 64-bit:

67 66 2e 0f 1f 84 00 00 00 00 00 nopw %cs:0x0(%eax,%eax,1)


-- 
H.J.