I constantly see the text (<perror@plt+0x2008e0>) as seen in the snippet below, but I am not sure if its making a call to perror of if the disassembler was having issues. Since it would be odd if the first thing the main function did was to call the exit code. Finally what does @plt refer to.

0000000000400540 <__libc_start_main@plt>:
  400540:   ff 25 0a 09 20 00    jmpq  *0x20090a(%rip)    # 600e50 <perror@plt+0x2008e0>

Let me know if more information is needed and I will update the question

2 Answers 2


PLT stands for Procedure Linkage Table. It is effectively a table of function addresses. More precisely, as illustrated here, the PLT is a table where each entry consists of a jump instruction to where the code of the function really is. The PLT thus consists of function stubs.

Calls to dynamically linked functions are compiled to calls to the PLT address, rather than the address where the function really is. Thanks to this indirection, external calls in a module can be implemented with a relative jump into the PLT. The dynamic linker updates the PLT with the runtime address of the actual code, which depends on where the called module is located in memory relative to the callee.

The problem solved by this extra level of indirection is dynamic linking where the address of the libraries cannot be predicted at compile time and the dynamic linker does not need to update the code itself (which would preclude sharing between instances of a library that is loaded at different addresses in different processes).

This explains <__libc_start_main@plt>. That the jump is indicated as into perror@plt is confusing information from the disassembler. <perror@plt+0x2008e0> means that the jump target is 0x2008e0 bytes after the start of the PLT entry for perror — if this was a jump into the code of the perror function, that would be one huge function! In fact the jump is to the real code of the main entry point, which happens to be located this many bytes from the perror PLT entry (if you're using GNU binutils, I think objdump picks the last PLT entry here). The binary is compiled without debugging symbols, so the code of all functions appears to the disassembler as a huge block of .text, and the debugger has no better way to name that particular address. If debugging symbols had been present then the disassembler would have extracted the function name from the debugging information in the binary.


So, first, the (%rip) refers to the content of the memory cell pointed by the value contained in %rip.

And, second, the <perror@plt+0x2008e0> refers to the symbol perror@plt (plus an offset of 0x2008e0.

If you want more details about how the PLT and the GOT work, feel free to ask another question (because it will fill several pages just to explain it nicely).

Note: This question was obviously for me !!! :-)

  • So i was actually only interested in what <perror@plt+0x2008e0> refers to , I think I will kill this question and ask another about what is GOT and PLT
    – RC1140
    Commented May 3, 2013 at 7:38
  • In fact, I already asked the question. But, basically PLT/GOT are tables to locate the functions from libraries that are dynamically loaded.
    – perror
    Commented May 4, 2013 at 19:05
  • Thanks again , once you mentioned PLT/GOT as things too research I found out what they were and how they work and what they mean.
    – RC1140
    Commented May 6, 2013 at 10:27
  • @perror: why the +offset? Does that mean symbol perror in the PLT at offset or does it mean perror at address of PLT plus offset? Besides, the several pages in your own Q&A are pretty short ;)
    – 0xC0000022L
    Commented May 6, 2013 at 13:02
  • I agree, I will improve my Q&A. I have some time this week, so I will work out on this. I know I left a lot of things aside (because I lack of time). Sorry...
    – perror
    Commented May 6, 2013 at 14:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.