标签: elf

我正在为一个类项目编写一些嵌入式代码，该项目当前（根据要求）创建了许多 srec 文件并合并它们。我希望能够将此代码加载到 QEMU 中，但它通常只对 ELF 文件满意。合并原始 ELF 文件而不是 srecs 的最有效方法是什么？同样可以接受的是，将 srec 转换回 ELF 并使生成的文件可加载的方法（objcopy 这样做似乎会产生相当损坏的文件（其他架构中没有架构）。这些工具必须能够使用 m68k 二进制文件，但是主机系统是普通的 x86。

readelf -l /bin/ls:

  LOAD           0x000000 0x08048000 0x08048000 0x18ff8 0x18ff8 R E 0x1000
  LOAD           0x019eec 0x08061eec 0x08061eec 0x003f4 0x01014 RW  0x1000

那么两个段之间的边界页既是只读的又是可读写的，这怎么可能呢？

我对此非常陌生，我有 elf 文件input.out，需要从中创建十六进制可执行文件。我正在使用 objcopy 创建 intel 十六进制格式的可执行文件，如下所示

objcopy -O ihex input.out out.hex

通过这个 out.hex 包含来自所有部分（.interp、.note.ABI-tag 等）的数据，但我不确定可执行文件是否需要所有这些数据。.text 部分足以创建可执行的十六进制，所以我可以按如下方式使用，还是需要更多部分

objcopy -j.text -O ihex input.out out.hex

另外，如果有任何好的参考来详细了解这一点，我无法通过 Goggling 找到太多内容。可能我不知道要搜索什么。

我想通过ELF文件获取源代码路径&&源名称，.debug_str部分包含我需要的内容，但如何过滤掉它们？

假设我fn在.textELF64可执行文件的某个部分中有某个功能.有没有办法知道fn函数所在的ELF文件的起始位置(以字节为单位)？请注意,我不需要知道它在链接时重定位的VA,而是它在ELF文件中的位置.

我正在 Linux X86_64 上工作。

我需要根据条目所代表的动态函数的名称来确定 ELF 文件中特定 PLT 条目的地址。我可以算出文件相对于地址的偏移量，但我需要能够确定地址。

如果我使用反汇编 ELF 文件，objdump -D -z elffile我会发现 objdump 对 PLT 中的每个条目使用符号名称。（objdump从哪里获取这些地址和符号名的关系？）

例子：

0000000000000041a2b0 fileno@plt:

如果我使用objdump -T elffile | grep fileno我会得到这样的东西：

0000000000000   DF *UND*  00000000000000000   GLIBC_2.2.5 fileno

我需要从“C”做的是在 ELF 文件中找到特定动态函数的 PLT 条目并获取地址。

背景是我正在修补现有的 ELF 文件，并且需要将函数调用重定向到不同的动态函数。我已经使用从 objdump 反汇编中收集的地址手动修补了 ELF 文件，并证明这适用于我的特定应用程序，我只需要能够从程序中执行此操作。我希望不必通过 objdump 反汇编程序代码来找出它如何获取 PLT 条目符号和地址。

我有一个 elf 文件，在使用 elfparser 分析映射文件和 elf 时，我看到一个名为 .Debug_info 的部分，它占用了最大的内存。

我正在使用 xt-xc++ 为 xtensa DSP 进行编译，我还没有使用 -g 选项，也没有使用 -o2 优化级别。

是否可以在发布版本中删除它？

我遇到了一个问题，该问题已在一篇好文章“共享库符号冲突（在 Linux 上）”中详细阐述。问题是，当执行和.so定义了同名函数时，如果.so调用这个函数名，它会调用执行中的那个函数，而不是.so本身的这个函数。

我们来谈谈这篇文章中的案例。我了解DoLayer()中的函数在编译时layer.o具有外部函数依赖性。DoThing()layer.o

但是在编译时libconflict.so，外部函数依赖项不应该就地解析并用conflict.o/DoThing()静态地址替换吗？

为什么layer.o/DoLayer()仍然使用动态链接来查找DoThing()？这是设计好的行为吗？

我可以看到很多复制的知识，这些函数在 .init_array 部分注册的函数具有命令行参数 argc 和 argv，如 main()，但我无法在网上找到任何实际发布的文档来证实情况确实如此。

是的，为了清楚起见，函数本身没有在 .init_array 中“声明”，但在那里声明了指向该函数的指针，“注册”该函数，并在启动期间由某个迭代器调用。问题仍然是：向我显示该迭代器传入的参数列表的一些文档。

我的目的是以一种微妙但通常安全的方式从动态库中更改这些参数，因此我想在内存中找到“真正的交易”——而不是从 /proc/self/ 中。

欲了解更多信息，请点击下面的链接。

一些堆栈溢出知识：在 Linux 上访问 main 之外的主要参数

即使是我最喜欢的 Oracle ( docs.oracle.com/cd/E23824_01/html/819-0690/chapter3-8.html ) 也只提到函数被调用，但没有承诺可能有什么参数。据我所知，与 elf 和 gcc 文档相同。

在 C/C++ UB 偏执狂的土地上，理想情况下，在我继续之前，我需要确定这是已记录的行为？它存在吗？可以通过某种方式暗示吗？

迄今为止的评论/答案摘要：

至少对于 GNU libc，此补丁发生了相关更改：BZ #974。\n https://sourceware.org/pipermail/libc-alpha/2005-July/019240.html（在 glibc\'s 中提到） ChangeLog.old/ChangeLog.16 条目 2005-04-13 HJ Lu.) \xe2\x80\x93\nIan Abbott

对我来说，这表明 glbc 维护者意识到传递 argc/argv/env 的要求 - 这不是偶然的 - 并将其扩展到主 exe 注册。它还告诉我们，它在该日期之前适用于动态库。

这是一个有趣的问题，这是否会约束其他 libc 实现者遵循该模式。

我试图更好地理解 Linux 中的运行时重定位，特别是谁在不同情况下执行它们。以下是我目前的理解，是否准确？

• 位置相关的静态链接可执行文件 - 无需运行时重定位
• 动态链接的可执行文件 - 动态链接器 ( ld.so) 加载库，然后执行重定位
• 静态链接 PIE - libc 启动代码执行重定位
• 动态链接器本身 -ld.so是一个自重定位的二进制文件

谢谢