RFC: Improving the disassembly of relro binaries.

Nick Clifton nickc@redhat.com
Mon Oct 10 10:25:00 GMT 2016


Hi Guys,

  I have been working on a patch to fix a problem reported by a Fedora
  user about objdump's less than helpful output when disassembling a
  dynamic executable compiled with -z relro enabled.  (1370275 in case
  anyone is interested).  The problem can be demonstrated with a small
  test case:

  % cat main.c
  #include <stdio.h>
  int main(void) { printf("Hello World\n"); return 0; }

  % gcc -g -DPIE -fPIE main.c
  % objdump -d a.out
  [...]
  0000000000400526 <main>:
    400526:	55                   	push   %rbp
    400527:	48 89 e5             	mov    %rsp,%rbp
    40052a:	bf d0 05 40 00       	mov    $0x4005d0,%edi
    40052f:	e8 cc fe ff ff       	callq  400400 <printf@plt>
  [...]

  % gcc -g -DPIE -fPIE -Wl,-z,relro -Wl,-z,now
  % objdump -d a.out
  [...]
  0000000000400516 <main>:
    400516:	55                   	push   %rbp
    400517:	48 89 e5             	mov    %rsp,%rbp
    40051a:	48 8d 3d 9f 00 00 00 	lea    0x9f(%rip),%rdi        # 4005c0 <__dso_handle+0x8>
    400521:	e8 da fe ff ff       	callq  400400 <_init+0x30>
  [...]

  Note how in the first objdump the call instruction is annotated with
  function name being called whereas in the second invocation the call
  goes to what appears to be a random address.

  I have developed a patch (attached) to change this behaviour so that
  objdump now shows:

  0000000000400516 <main>:
    400516:	55                   	push   %rbp
    400517:	48 89 e5             	mov    %rsp,%rbp
    40051a:	48 8d 3d 9f 00 00 00 	lea    0x9f(%rip),%rdi        # 4005c0 <__dso_handle+0x8>
    400521:	b8 00 00 00 00       	mov    $0x0,%eax
    400526:	e8 d5 fe ff ff       	callq  400400 <.plt.got>

  Which is slightly more helpful.  Plus the patch also now arranges for
  the PLT to be disassembled like this:

  0000000000400400 <.plt.got>:
    400400:	ff 25 e2 0b 20 00    	jmpq   *0x200be2(%rip)        # 600fe8 <printf@GLIBC_2.2.5 ?>
    400406:	66 90                	xchg   %ax,%ax
    400408:	ff 25 e2 0b 20 00    	jmpq   *0x200be2(%rip)        # 600ff0 <__libc_start_main@GLIBC_2.2.5 ?>
    40040e:	66 90                	xchg   %ax,%ax
    400410:	ff 25 e2 0b 20 00    	jmpq   *0x200be2(%rip)        # 600ff8 <__gmon_start__ ?>
    400416:	66 90                	xchg   %ax,%ax

  So the user can see that the first entry in the .plt.got section is a
  jump to the printf function.

  I added the ? character at the end of the interpreted addresses in
  order to indicate that these symbols are undefined and in theory they
  could remain unresolved or even replaced with some other function.

  Rather than just go ahead and apply this patch however, I thought that
  I would ask you guys first if you had any thoughts or suggestions on
  the enhancement.  Especially given that it changes objdump's output.
  So - any comments ?

Cheers
  Nick

Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1370275

Here is the body of the proposed patch.  The real patch is actually
quite a lot larger as there are a lot of linker tests that need to be
tweaked to match the new output from objdump.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr1370275.patch
Type: text/x-patch
Size: 3055 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20161010/53a568a7/attachment.bin>


More information about the Binutils mailing list