Re: New .nops directive, to aid Linux alternatives patching?

[Andrew Cooper <andrew dot cooper3 at citrix dot com>]

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:

.nop -(((144f-143f)-(141b-140b)) > 0)*((144f-143f)-(141b-140b))

and evaluates to 0 when 144f-143f is equal to or smaller than 141b-140b.

~Andrew