__libc_start_main中发生了什么? [英] What's going on in __libc_start_main?

查看:206
本文介绍了__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 is jmp *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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆