title: Understanding the relocation table output from readelf
body: <p>For example, running the command:</p>
  
  <pre><code>readelf -r /bin/ls | head -n 20
  </code></pre>
  
  <p>I get the following output:</p>
  
  <pre><code>Relocation section '.rela.dyn' at offset 0x15b8 contains 7 entries:
    Offset          Info           Type           Sym. Value    Sym. Name + Addend
  000000619ff0  003e00000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0
  00000061a580  006f00000005 R_X86_64_COPY     000000000061a580 __progname + 0
  00000061a590  006c00000005 R_X86_64_COPY     000000000061a590 stdout + 0
  00000061a5a0  007800000005 R_X86_64_COPY     000000000061a5a0 optind + 0
  00000061a5a8  007a00000005 R_X86_64_COPY     000000000061a5a8 optarg + 0
  00000061a5b0  007400000005 R_X86_64_COPY     000000000061a5b0 __progname_full + 0
  00000061a5b8  007700000005 R_X86_64_COPY     000000000061a5b8 stderr + 0
  
  Relocation section '.rela.plt' at offset 0x1660 contains 105 entries:
    Offset          Info           Type           Sym. Value    Sym. Name + Addend
  00000061a018  000100000007 R_X86_64_JUMP_SLO 0000000000000000 __ctype_toupper_loc + 0
  00000061a020  000200000007 R_X86_64_JUMP_SLO 0000000000000000 getenv + 0
  00000061a028  000300000007 R_X86_64_JUMP_SLO 0000000000000000 sigprocmask + 0
  00000061a030  000400000007 R_X86_64_JUMP_SLO 0000000000000000 raise + 0
  00000061a038  007000000007 R_X86_64_JUMP_SLO 00000000004020a0 free + 0
  00000061a040  000500000007 R_X86_64_JUMP_SLO 0000000000000000 localtime + 0
  00000061a048  000600000007 R_X86_64_JUMP_SLO 0000000000000000 __mempcpy_chk + 0
  </code></pre>
  
  <p>I do not understand this output and wanted some clarification.</p>
  
  <p>Does the 1st column, offset, indicate where these symbolic references are in the .text segment?  What is meant by the Info and Type columns, I thought relocations just mapped a symbol reference to a definition, so I don't understand how there can be different types?  Why do certain symbol names have 0 as the address for their value... I can't imagine they all map to the same spot in the text segment?  Finally, why does the relocation table even exist in the final executable? Doesn't it take up extra space and all the references have already been resolved for the last link command that generates the executable?</p>