问题标签 [objcopy]

我正在构建一个调试系统来调试在远程系统中崩溃的 exe（例如 coredump）。调试符号连同核心转储（例如 coredump.dbg、coredump_core.dump）被发送到主机系统。在主机系统中，当我使用 GDB 分析转储时，我得到了下面提到的所有这些错误。请一些人帮助如何将共享库发送到主机。如果是，那么如何？

我应该如何在主机系统的调试符号中链接共享库

以下是错误

1. readelf -a coredump.dbg

2. gdb coredump.dbg coredump_core.dump

3.文件 coredump.dbg

我们有一个带有自定义部分的链接器脚本，出于某些 IEC 合规性测试原因而添加了该部分。然而，自从添加这个部分之后，通过创建的二进制大小objcopy -O binary input output已经从 ~150kbytes 激增到 ~512Mbytes。

我已将其追溯到缺少该(NOLOAD)属性的部分。而且我也可以解释为什么二进制文件是 512Mbytes。

我们的记忆如下：

最初定义的部分是：

如果CUSTOM_LOCATION:替换CUSTOM_LOCATION (NOLOAD):为生成的二进制文件是正常的。没有(NOLOAD)二进制大小是~512Mbytes。

我正在寻找这个二进制文件变得如此之大的原因。生成二进制文件(NOLOAD)（或不存在）意味着什么？objcopy

第二个问题，在本节的最后我们说} > CUSTOM_SECTION AT > ram我们可以不用这个指令吗？可以直接替换} > ram吗？（这可以CUSTOM_SECTION从MEMORY零件中删除吗？

我在生成的map文件中没有看到任何差异

我在 Windows 10 上使用 objcopy 将我的 dll 嵌入到 exe 中并加载它。使用 32 位二进制 dll 文件进行 32 位编译时，它运行良好，因为加载我的 dll 时没有错误。

如何设置 objcopy 参数以便获得 64 位二进制对象文件？如果不可能，objcopy是否有任何替代方案？当我将它编译为 64 位时，我的 dll 没有被加载，如果我尝试使用 64 位的目标文件编译可执行文件，它会返回错误，指出我的目标文件与 64 位编译不兼容。

所以例如在 gcc 编译期间，我必须这样做

如果我删除-m32它不会编译，因为 somedll.o 设置为 32 位，即使它在 dll 中是 64 位，所以这就是我的LoadLibrary()函数无法加载它的原因。

我有一个涉及链接脚本的 STM32 项目，该链接脚本旨在用“.firmware_header”部分结束图像的末尾。思路是这个header包含了图片的crc，这个点之后应该没有内容。但是，当我这样做时

在最后一部分之后存在一些数据，出于某种原因，映像启动需要这些数据。如果我将此神秘块归零，则映像无法启动。第一个问题，从我看到的elf部分来看，.firmware_header后面应该没有部分，数据是从哪里来的？第二个问题是，为什么在启动时需要这些数据？下面是我的链接器脚本、readelf 输出和神秘数据的屏幕截图。

arm-none-eabi-readelf -a ./fw.elf：

读完这个答案后，我立刻想到：

为什么我必须确切地知道它是 Little Endian 还是 Big Endian？这是否意味着不是简单地复制我的二进制输入数据，而是objcopy根据选择的 Endianess 以某种方式破坏数据？

手头的例子是：

如果这是真正的二进制数据，objcopy应该不必关心，对吧？以后读取数据的任何内容都必须，但objcopy不应该...

是否objcopy根据选项给出的位数和字节序来破坏数据-O？

我需要在 C# 中处理一些由 OBJCOPY 实用程序提供的转储。

在命令提示符下使用时，我会这样使用它：

这就是我将 .text 部分的 RAW 内容获取到文件中的方式。

在 C# 中，我编写了一个小型进程包装器来启动外部程序

我不知道如何欺骗 OBJDUMP 并将 RAW 转储直接获取到内存中，而无需外部文件，然后打开并读取该文件的二进制文件。

这篇文章中的一个聪明人
如何在 Linux 上检查 ELF 文件的数据部分的内容？

给出了一个 linux 提示以在 stdout 上重定向（我认为我可以捕获），但我无法在 Win 上重现。

那么，聪明的头脑可以想出一个窍门，这可能吗？

先感谢您，

我正在尝试使用以下命令将一些 elf 文件复制到 ihex：

我正在尝试将四个部分复制到 ihex。问题是 objcopy 只复制其中的前三个，没有 .rodata。

我的问题是为什么 objcopy 只复制前三个部分而不是第四部分（.rodata）？

从 readelf 分配的部分

精灵信息

• 地图文件
• 对象转储 -h
• 阅读器-S

我正在尝试将一个部分从专有二进制文件移动到我自己的目标文件中，以便我可以链接它。但是，ARM 架构数据没有正确添加到生成的目标文件中，因此它没有链接到最终的可执行文件中。

我使用以下命令执行此操作：

当我尝试将此目标文件链接到我的可执行文件中时，我得到：

这似乎是因为生成的对象中没有 ARM 架构数据。我已经将生成的 fw_data.o 与使用 objdump 和 readelf 的编译器（例如 main.o）生成的目标文件进行了比较。成功链接的对象文件似乎都有.ARM.attributes我生成的对象没有的部分。

作为测试，我从 main.o 手动转储了该部分并将其添加到我的 objcopy 命令中：

这成功地将部分添加到对象，但编译器似乎没有拾取它，它仍然无法链接。比较 main.o 和 fw_data.o 我发现这些部分的类型不同：

我还尝试将 .data 部分转储到文件并使用 ld 创建 fw_data.o ，因为这个问题表明：确定 GNU binutils 的目标和体系结构的“正确”方法是什么？

这会导致生成的相同问题，fw_data.o并且仍然无法链接。

如何在使用 objcopy 生成的目标文件中正确设置 ARM_ATTRIBUTES 部分？

因为我必须使用无法处理 SREC 文件中不同长度的行的第三方引导加载程序，所以我需要一种方法来objcopy创建 SREC 文件，其中每S1行都具有相同的长度（如果没有提供来自 ELF 文件的信息, 应填写FF)。

我们可以假设地址增量是一致的，所以我们不会在地址中跳得高于我们指定的行长度。所以我们不需要创建所有的中间行，FF例如

我发现了--srec-len但这只设置了最大长度大小。
我需要一些设置固定长度大小的东西，有什么我可以使用的吗？

一种可能的解决方案是使用（第三方）工具从 objcopy 转换早期生成的 SREC 文件

strip 和 objcopy 二进制实用程序都支持 [--remove-section=sectionname] 选项。

这两个选项有区别吗？是否存在应该优先于另一个的情况？