What's going on in __libc_start_main?

c linux gcc dynamic-linking
gone picture gone · Jun 6, 2013 · Viewed 17.1k times · Source

I'm really trying to understand the steps from high level code -> executable.. but am having some difficulties.

I've written an empty int main() {} C file and am trying to decipher the disassembly via objdump -d. Here's what's going on:

  • in _start, set up alignment, push arguments on stack, call __libc_start_main
  • in __libc_start_main, the first line to execute is jmp *0x8049658

However, upon using objdump -R to check out the relocation records, the value in 0x8049658 is __libc_start_main itself!

I'm missing something here..

edit: here's some of the source;

 080482c0 <__libc_start_main@plt>:
 80482c0:       ff 25 58 96 04 08       jmp    *0x8049658
 80482c6:       68 08 00 00 00          push   $0x8
 80482cb:       e9 d0 ff ff ff          jmp    80482a0 <_init+0x2c>

Disassembly of section .text:

080482d0 <_start>:
 80482d0:       31 ed                   xor    %ebp,%ebp
 80482d2:       5e                      pop    %esi
 80482d3:       89 e1                   mov    %esp,%ecx
 80482d5:       83 e4 f0                and    $0xfffffff0,%esp
 80482d8:       50                      push   %eax
 80482d9:       54                      push   %esp
 80482da:       52                      push   %edx
 80482db:       68 50 84 04 08          push   $0x8048450
 80482e0:       68 e0 83 04 08          push   $0x80483e0
 80482e5:       51                      push   %ecx
 80482e6:       56                      push   %esi
 80482e7:       68 d0 83 04 08          push   $0x80483d0
 80482ec:       e8 cf ff ff ff          call   80482c0 <__libc_start_main@plt>
 80482f1:       f4                      hlt
 80482f2:       66 90                   xchg   %ax,%ax



 DYNAMIC RELOCATION RECORDS
OFFSET   TYPE              VALUE 
08049644 R_386_GLOB_DAT    __gmon_start__
08049654 R_386_JUMP_SLOT   __gmon_start__
08049658 R_386_JUMP_SLOT   __libc_start_main

Answer

Colin D Bennett picture Colin D Bennett · Jun 11, 2013

The first block, ending in "@plt", is the procedure linkage table (https://stackoverflow.com/a/5469334/994153). The jmp *0x8049658 is an indirect branch instruction, so it actually is jumping to __libc_start_main wherever it actually ends up getting loaded in RAM at runtime.

The real RAM address of __libc_start_main is found in the DYNAMIC RELOCATION RECORDS table, which is created in RAM by the dynamic loader when the program is loaded.

Related questions

`bash: ./a.out: No such file or directory` on running executable produced by `ld`

Here is a Hello World code in C: // a.c #include <stdio.h> int main() { printf("Hello world\n"); return 0; } I compile it as gcc a.c, which produces a.out as expected and ./a.out prints Hello …

Read More
use RPATH but not RUNPATH?

This page - http://labs.qt.nokia.com/2011/10/28/rpath-and-runpath/ - says about order for library search in ld.so: Unless loading object has RUNPATH: RPATH of the loading object, then the RPATH of its loader (unless it has a RUNPATH), ..., …

Read More
Where is the <conio.h> header file on Linux? Why can't I find <conio.h>?

Possible Duplicate: How to implement getch() function of C in Linux? What is the equivalent Linux version of the conio.h header file from MS-DOS? Is there a way to replace its functionality? e.g. getch() I'm using gcc and …

Read More