标签: elf

我在某处读到（至少从 Linux v. 2.6 开始）所有用户空间代码都放置在虚拟内存地址空间中的加载地址 0x8048000 处。

我自己的观察证实了这一点。我做了一个

cat /proc/......../maps

对于多个进程，进程'程序的第一部分text总是从'0x8048000'开始。

此外，C 库启动代码和所有其他运行时好东西似乎都映射在此默认值之后。

这构成了近 128 M 的地址空间，考虑到 0xC0000000 - 0x8048000 仍然是用户空间内容的几乎 3G 地址空间，这并不多。

所以我的问题是为什么？

我们正在处理虚拟地址，与其他程序的干扰或重叠是由 VM 工作方式的定义排除的。

0x00000000 到 0x8048000 范围内是否有一些固定/默认映射？

除了默认起始地址落在页面边界这一事实之外，选择这个数字而不是任何其他值的理由是什么？

我正在研究我的 C 程序，我是 Linux/UNIX 开发的新手，正在四处看看。

我创建了一个简单的 Hello world C 程序，并正在检查编译过程。

我试图读取最终可执行文件的文件头并得到输出如下

$ objdump -f my_output
file format elf32-i386
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x08048320**

我了解 elf32-i386 部分，但我不太确定标题的其他部分。

D_PAGED与需求分页有某种关系吗？是什么 EXEC_P, HAS_SYSMS意思？是起始地址，程序的逻辑地址main()？

;TL-DR -答案：因为缺少动态链接器 ld-linux-x86-64.so.2。

我已经-ro,loop在/mnt/foo.

它包含以下内容（/mnt/foo是挂载点）：

\n-rwxr-xr-x 1 root root 110088 jan 17 2013 /mnt/foo/bin/ls\n-rw-r--r-- 1 root root 5212 jul 23 09:35 /mnt/foo/etc/ ld.so.cache\n-rw-r--r-- 1 个根 root 7 月 23 日 5 日 09:35 /mnt/foo/etc/ld.so.conf\n-rw-r--r-- 1 个根根 31168 maj 23 2013 /mnt/foo/lib/libacl.so.1\n-rw-r--r-- 1 root 根 18624 maj 20 2013 /mnt/foo/lib/libattr.so.1\n- rwxr-xr-x 1 根 1853400 okt 12 2013 /mnt/foo/lib/libc.so.6\n-rw-r--r-- 1 根 14664 okt 12 2013 /mnt/foo/lib/libdl .so.2\n-rw-r--r-- 1根根256224 mar 11 2013 …

如何从 ELF 文件中单独提取可加载程序头？通过使用 readelf 检查二进制文件，可以获得类似于以下内容的输出：

$ readelf -l helloworld

Elf file type is EXEC (Executable file)
Entry point 0x400440
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R E    8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x000000000000070c 0x000000000000070c  R E    200000
  LOAD           0x0000000000000e10 0x0000000000600e10 0x0000000000600e10
                 0x0000000000000230 0x0000000000000238  RW     200000
  DYNAMIC        0x0000000000000e28 0x0000000000600e28 0x0000000000600e28 …

我正在尝试将 Android 应用程序移植到 Linux（不要笑:)，但我遇到了一个问题。app_process在添加可执行权限后尝试执行 Android 可执行文件 ( )./app_process时表示它不存在，但cat ./app_process有效。

同样在我的文件管理器（Pantheon Files）中，可执行文件显示了共享库图标。

有什么方法可以让这些在 Linux 上执行。

例如grep，如果一个程序当前正在运行，而用户执行另一个实例，那么这两个实例是否共享.text它们之间的只读部分以节省内存？主要可执行文本的共享是否与共享库类似？

这种行为是否在 Linux 中表现出来？如果是这样，其他Unices 也这样做吗？

如果这不是在 Linux 中完成的，那么实现通常作为共享库并行运行多个实例的可执行文件是否有任何好处，调用的可执行文件只需调用库中的主函数？

您可以从以下位置获得 eu-readelf：

$ sudo apt-get install elfutils

我只是想知道为什么你会使用一个而不是另一个？

如何file尽快区分 ELFves 和脚本？

我不需要任何进一步的细节，只需要ELF、script ( /plaintext ) 或other/error。

我有一个快速的问题。我使用以下代码从 ac 代码生成了一个 ELF 二进制文件：

gcc -o simple simple.c

然后我为那个 ELF 二进制文件做 objdump：

objdump --disassemble-all simple

我已经检查了我的目录ls -a，那里没有 .o 文件。我的问题仍然是如何objdump向我展示完整的反汇编代码？是否objdump在二进制文件中进行静态分析以覆盖所有代码？

查看运行objdump -Ton生成的以下输出片段libc.so.6：

000000000009f8a0 g    DF .text  000000000000001d (GLIBC_2.2.5) aio_write64
0000000000119d00 g    DF .text  0000000000000034  GLIBC_PRIVATE __pread64_nocancel
000000000009aae0 g    DF .text  00000000000003c0  GLIBC_2.34  pthread_rwlock_timedwrlock
0000000000133db0 g    DF .text  0000000000000354  GLIBC_2.2.5 __backtrace_symbols
00000000001184f0  w   DF .text  00000000000006c2  GLIBC_2.23  fts64_read
000000000009aae0 g    DF .text  00000000000003c0 (GLIBC_2.2.5) pthread_rwlock_timedwrlock

输出的第 1 行和第 4 行具有相同的GLIBC版本字符串，但其中一个包含在括号中，而另一行则没有。我在objdump许多其他elf二进制文件的输出中观察到了这种差异。(GLIBC_2.2.5)和GLIBC_2.2.5输出之间有什么细微的区别吗objdump？