binutils-gdb/ld/testsuite/ld-i386/pr20244-2a.d
Andrew Burgess 202be274a4 opcodes/i386: remove trailing whitespace from insns with zero operands
While working on another patch[1] I had need to touch this code in
i386-dis.c:

  ins->obufp = ins->mnemonicendp;
  for (i = strlen (ins->obuf) + prefix_length; i < 6; i++)
    oappend (ins, " ");
  oappend (ins, " ");
  (*ins->info->fprintf_styled_func)
    (ins->info->stream, dis_style_mnemonic, "%s", ins->obuf);

What this code does is add whitespace after the instruction mnemonic
and before the instruction operands.

The problem I ran into when working on this code can be seen by
assembling this input file:

    .text
    nop
    retq

Now, when I disassemble, here's the output.  I've replaced trailing
whitespace with '_' so that the issue is clearer:

    Disassembly of section .text:

    0000000000000000 <.text>:
       0:	90                   	nop
       1:	c3                   	retq___

Notice that there's no trailing whitespace after 'nop', but there are
three spaces after 'retq'!

What happens is that instruction mnemonics are emitted into a buffer
instr_info::obuf, then instr_info::mnemonicendp is setup to point to
the '\0' character at the end of the mnemonic.

When we emit the whitespace, this is then added starting at the
mnemonicendp position.  Lets consider 'retq', first the buffer is
setup like this:

  'r' 'e' 't' 'q' '\0'

Then we add whitespace characters at the '\0', converting the buffer
to this:

  'r' 'e' 't' 'q' ' ' ' ' ' ' '\0'

However, 'nop' is actually an alias for 'xchg %rax,%rax', so,
initially, the buffer is setup like this:

  'x' 'c' 'h' 'g' '\0'

Then in NOP_Fixup we spot that we have an instruction that is an alias
for 'nop', and adjust the buffer to this:

  'n' 'o' 'p' '\0' '\0'

The second '\0' is left over from the original buffer contents.
However, when we rewrite the buffer, we don't afjust mnemonicendp,
which still points at the second '\0' character.

Now, when we insert whitespace we get:

  'n' 'o' 'p' '\0' ' ' ' ' ' ' ' ' '\0'

Notice the whitespace is inserted after the first '\0', so, when we
print the buffer, the whitespace is not printed.

The fix for this is pretty easy, I can change NOP_Fixup to adjust
mnemonicendp, but now a bunch of tests start failing, we now produce
whitespace after the 'nop', which the tests don't expect.

So, I could update the tests to expect the whitespace....

...except I'm not a fan of trailing whitespace, so I'd really rather
not.

Turns out, I can pretty easily update the whitespace emitting code to
spot instructions that have zero operands and just not emit any
whitespace in this case.  So this is what I've done.

I've left in the fix for NOP_Fixup, I think updating mnemonicendp is
probably a good thing, though this is not really required any more.

I've then updated all the tests that I saw failing to adjust the
expected patterns to account for the change in whitespace.

[1] https://sourceware.org/pipermail/binutils/2022-April/120610.html
2022-05-27 14:12:33 +01:00

32 lines
722 B
Makefile

#source: pr20244-2.s
#as: --32
#ld: -m elf_i386 -z noseparate-code
#objdump: --sym -dw
.*: +file format .*
SYMBOL TABLE:
#...
0+8048085 l i .text 00000000 bar
#...
0+8048086 g F .text 00000000 _start
#...
0+8048084 g i .text 00000000 foo
#...
Disassembly of section .text:
0+8048084 <foo>:
+[a-f0-9]+: c3 ret
0+8048085 <bar>:
+[a-f0-9]+: c3 ret
0+8048086 <_start>:
+[a-f0-9]+: ff 15 a8 90 04 08 call \*0x80490a8
+[a-f0-9]+: ff 25 ac 90 04 08 jmp \*0x80490ac
+[a-f0-9]+: c7 05 ac 90 04 08 00 00 00 00 movl \$0x0,0x80490ac
+[a-f0-9]+: 83 3d a8 90 04 08 00 cmpl \$0x0,0x80490a8
+[a-f0-9]+: b9 fc ff ff ff mov \$0xfffffffc,%ecx
#pass