Home Original page

New .nops directive, to aid Linux alternatives patching?

H.J. Lu hjl.tools@gmail.com
Mon Feb 12 13:58:00 GMT 2018 
On Mon, Feb 12, 2018 at 5:41 AM, Maciej W. Rozycki <macro@mips.com> wrote:
> On Mon, 12 Feb 2018, H.J. Lu wrote:
>
>> >> If you were to do that, why not simply remove the 255 maximum limit,
>> >> rather than having a user pass two identical numbers?  That said, I
>> >> think the current implementation with 255 is probably fine; My example
>> >> of ~45 is pushing it, but I expect that any example trying to use 64 or
>> >> more almost certainly has a better way to do the same thing.
>> >
>> >  What's the point of this arbitrary limit though?  Does it have any
>> > benefit to the user?
>> >
>> >  Otherwise may I remind what the GNU Coding Standards say [1]:
>> >
>> > 'Avoid arbitrary limits on the length or number of any data structure,
>> > including file names, lines, files, and symbols, by allocating all data
>>
>> Support arbitrary .nop directive size requires very intrusive changes
>> and provides very little benefits.
>
>  Why?  Effectively it's just like a `.byte' pseudo-op with a long argument
> list, except that the values produced are implicit.  What's so intrusive
> about emitting a longish stream of bytes?
>

Here is the typical usage:

[hjl@gnu-6 nop-4]$ cat t.S
.L_orig_s:
.L_orig_e:
     .nop (-(((.L_repl_e1 - .L_repl_s1) - (.L_orig_e - .L_orig_s)) >
0) * ((.L_repl_e1 - .L_repl_s1) - (.L_orig_e - .L_orig_s)))
.L_orig_p:

    .section .discard, "a", @progbits
    .byte 0xff + (.L_repl_e1 - .L_repl_s1) - (.L_orig_p - .L_orig_s)

    .section .altinstr_replacement, "ax", @progbits
.L_repl_s1:
.L_fill_rsb_loop:
    jnz .L_fill_rsb_loop
    mov %rax, %rsp
.L_repl_e1:
[hjl@gnu-6 nop-4]$ ./as -o t.o t.S
[hjl@gnu-6 nop-4]$ objdump -dwr t.o

t.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <.text>:
   0: 0f 1f 44 00 00        nopl   0x0(%rax,%rax,1)

Disassembly of section .altinstr_replacement:

0000000000000000 <.altinstr_replacement>:
   0: 75 fe                jne    0x0
   2: 48 89 c4              mov    %rax,%rsp
[hjl@gnu-6 nop-4]$

My implementation uses the existing relaxation frame work.
When we are processing .nop, we don't know exactly how big the
the NOP size will be.  We allocate a frag with the maximum size
and set the exact size after relaxation.  After relaxation is done,
all frags are converted to rs_fill.  We can add rs_fill_nop to
support arbitrary .nop directive size. But I don't know if it is
necessary.

-- 
H.J.
More information about the Binutils mailing list