New .nops directive, to aid Linux alternatives patching?

H.J. Lu
Thu Feb 8 20:36:00 GMT 2018

On Thu, Feb 8, 2018 at 12:33 PM, Andrew Cooper
<> wrote:
> On 08/02/2018 20:28, H.J. Lu wrote:
>> On Thu, Feb 8, 2018 at 12:27 PM, H.J. Lu <> wrote:
>>> On Thu, Feb 8, 2018 at 12:18 PM, Andrew Cooper
>>> <> wrote:
>>>> On 08/02/2018 20:10, H.J. Lu wrote:
>>>>> On Thu, Feb 8, 2018 at 11:26 AM, Andrew Cooper
>>>>> <> wrote:
>>>>>> Hello,
>>>>>> I realise this is a little bit niche, but how feasible would it be to
>>>>>> introduce a new .nops directive which takes a size parameter, and
>>>>>> outputs long nops covering the number of specified bytes?
>>>>> Sounds to me you want a pseudo NOP instruction:
>>>>> pseudo-NOP N
>>>>> which generates a long NOP with N byte.  Is that correct.  If yes,
>>>>> what is the range of N?
>>>> Currently 255 based on other implementation limits, and I expect that
>>>> ought to be long enough for anyone.  There is one existing user for
>>>> N=43, and I expect that to grow a bit.
>>>> The real answer properly depends at what point it is more efficient to
>>>> jmp rather than wasting decode bandwidth decoding nops, and I don't know
>>>> the answer, but expect that it isn't larger than 255.
>>> How about
>>> {nop} N
>>> If N is less than 15 bytes, it generates a long nop.   Otherwise, we use a jump
>>> instruction over nops.  Does it work for you?
>> N will be limited to 255.
> Do you mean up to 255 bytes of adjacent long nops, or still a jump if
> over 15 bytes?  For alternatives in the range of 15-30, a jmp is almost
> certainly slower than executing through the nops.  The ORM isn't clear
> where the split lies, and I expect it is very uarch specific.

How about this

{nop} N, L
{nop} N

N is < =255. If L is missing, L is 15.

If N < L then
  Long NOPs up to N bytes
  jmp + long nops up to N bytes.


More information about the Binutils mailing list