__libc_start_main中发生了什么? [英] What's going on in __libc_start_main?
问题描述
我真的想从高级代码->可执行文件中理解这些步骤.但是遇到了一些困难.
I'm really trying to understand the steps from high level code -> executable.. but am having some difficulties.
我写了一个空的int main() {}
C文件,并试图通过objdump -d
解密反汇编.这是怎么回事:
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:
- ,设置对齐方式,将参数压入堆栈,调用
__libc_start_main
- 在
__libc_start_main
中,要执行的第一行是jmp *0x8049658
- in
_start
, set up alignment, push arguments on stack, call__libc_start_main
- in
__libc_start_main
, the first line to execute isjmp *0x8049658
但是,使用objdump -R
检出重定位记录时,0x8049658
中的值就是__libc_start_main
本身!
However, upon using objdump -R
to check out the relocation records, the value in 0x8049658
is __libc_start_main
itself!
我在这里想念东西.
这是其中的一些内容;
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
推荐答案
以"@plt"结尾的第一个块是过程链接表(https://stackoverflow.com/a/5469334/994153 ). jmp *0x8049658
是间接分支指令,因此实际上 最终会在运行时跳转到__libc_start_main
.
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.
__libc_start_main
的实际RAM地址在动态重新记录"表中找到,该表在加载程序时由动态加载程序在RAM中创建.
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.
这篇关于__libc_start_main中发生了什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!