New .nops directive, to aid Linux alternatives patching?

H.J. Lu hjl.tools@gmail.com
Sun Feb 11 17:19:00 GMT 2018


On Sun, Feb 11, 2018 at 8:45 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> 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)
>

I implemented:

.nop SIZE [, MAX_NOP]

where the maximum size is 255 bytes.  Should we go with

.nop MAX_SIZE, SIZE [, MAX_NOP]

to support more than 255 bytes?


-- 
H.J.



More information about the Binutils mailing list