What's going on in __libc_start_main?

Question

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

Scales

Also, can you post the full assembly code you are referencing? It will make our lives much easier. – Gurtner

What happens if you step through the assembly with a debugger? It's possible that the dynamic linker overwrites the value at memory location 0x8049658, so by the time the program gets to the jmp *0x8049658 instruction, it jumps to whatever value got written there at runtime. – Vainglory

@AdamRosenfield I'm not 100% how to do that. I know how to set gdb up to step through my C code, but don't know how to do it for the assembly :S – Scales

@AdamRosenfield gdb won't even let me run the program. I get [Inferior 1 (process 24455) exited with code 01] – Scales

__libc_start_main@plt is not the same symbol as __libc_start_main – Possie

@Zak You should not need any special gdb setup. Simply use the gdb commands si and ni to execute your program one instruction at a time. – Ludmilla

@MichaelBurr well no plain __libc_start_main symbol appears in my objdump – Scales

Answer 1

The first block, ending in "@plt", is the procedure linkage table (https://mcmap.net/q/14447/-what-does-plt-mean-here). 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.

Volga

It actually gets resolved on first call these days, this blog post shows how one can watch the dynamic linker working at run-time dustin.schultz.io/how-is-glibc-loaded-at-runtime.html – Oilcloth

^ This is called lazy loading for those searching by keyword. – Upstroke