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