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

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Feb 8, 2018 at 3:47 PM, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 08/02/2018 20:36, H.J. Lu wrote:
>> On Thu, Feb 8, 2018 at 12:33 PM, Andrew Cooper
>> <andrew.cooper3@citrix.com> wrote:
>>> On 08/02/2018 20:28, H.J. Lu wrote:
>>>> On Thu, Feb 8, 2018 at 12:27 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>> On Thu, Feb 8, 2018 at 12:18 PM, Andrew Cooper
>>>>> <andrew.cooper3@citrix.com> wrote:
>>>>>> On 08/02/2018 20:10, H.J. Lu wrote:
>>>>>>> On Thu, Feb 8, 2018 at 11:26 AM, Andrew Cooper
>>>>>>> <andrew.cooper3@citrix.com> 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
>> else
>>   jmp + long nops up to N bytes.
>> fi
>
> I'm afraid that I don't think that will be very helpful in that form.
> Are there technical reasons why you don't want to emit more than a
> single 15byte long nop?
>

Doesn't

{nop} 28, 40

generate 2 x 14-byte nops?


-- 
H.J.