问题标签 [objcopy]

据我所知，objcopy能够将调试符号（使用 -g 标志编译）从可执行二进制文件中移出。我发现了这个问题，但是符号外包只有通用的方法。

但是当我的可执行文件使用一些非常大的 .so 和 .a 文件时，我该怎么办？

我想在一个没有足够位置放置调试符号的小环境中分析我的应用程序。整个项目是使用 -g 选项构建的。稍后仅在处理配置文件日志时才需要调试符号。

我必须在带有 ARM Cortex A8 的项目中使用为 ARM Cortex M4 预编译的库。链接器自然会给我一个错误：

file "..." has a Tag_CPU_arch_profile attribute value of "77" that is different than one previously seen ("65"); combining incompatible files

我可以使用 arm-none-eabi-objcopy 来转换库吗？它不包含特定于外围设备或微控制器本身的代码。两者都是ARM。似乎有可能，但如何？

What are the intel hex records type 03 or 05 doing in iHex program?

Record type 03: Start Segment Address For 80x86 processors, specifies the initial content of the CS:IP registers. The address field is 0000, the byte count is 04, the first two bytes are the CS value, the latter two are the IP value.

Record type 05: Start Linear Address The address field is 0000 (not used) and the byte count is 04. The four data bytes represent the 32-bit value loaded into the EIP register of the 80386 and higher CPU.

Do these even make sense for an ARM program?

Whenever I generate .hex to program embedded ARM, the ending looks something like this:

:10851400B4040020BC040020BC040020C4040020D7
:10852400C4040020CC040020CC040020D404002087
:10853400D4040020DC040020DC040020E404002037
:10854400E4040020EC040020EC040020F4040020E7
:10855400F4040020FC040020FC040020FFFFFFFFC3
:048564000000020011
:0400000508002910B6
:00000001FF

I've edited the programming app to ignore this record, and just today a coworker reported his compiler produced a 03 type record on the second-to-last line, which prevented programming the MPU.

Why does objcopy create these records? Can I stop it from doing it?

Relevant Makefile lines:

我尝试gcc使用objcopy. 我的 C 代码如下所示：

当我创建我的二进制文件时

代码部分 ( .text) 链接正确，但数据部分 ( .rdata) 只是放在我的代码部分后面，没有与我的代码部分链接。如果我访问数据部分中的任何内容，它将从 0x0x401000 加载某些内容，而不是从正确的位置加载并崩溃。

有没有办法解决这个问题？

PS：工作C代码是：

我正在使用 objcopy 删除一些必要的脚本，以将资源文件（zip 文件）嵌入闪存（ARM 嵌入式事物）中。

我正在使用这样的 objcopy：

我需要知道的是 _end 和 _size 符号的宽度是多少。我只能猜测 _start 是一个可以像字节数组一样访问的地址：extern uint8_t _binary_input_zip_start[];。我假设 _end 和 _size 是“本机”int-size，我想我可以放心地假设我可以将它们解释为 uint32_t。

不过我不能确定。我在 objcopy 的文档中找不到任何与“大小”相关的内容：https ://sourceware.org/binutils/docs/binutils/objcopy.html

我正在尝试在 Windows 上创建等效的 pdb 文件，以使用单独的调试信息文件进行构建。我安装并尝试使用 gobjdump 从一个小型 hello world 程序（testDebugging）中删除调试信息。我使用 eclipse 构建了代码，二进制文件运行良好。

我运行 gobjcopy --strip-debug testDebugging 的那一刻，二进制文件的大小减小了。但是当我现在尝试运行二进制文件时，它会因“-bash: ./testDebugging: Malformed Mach-o file”而失败

即使打开了详细选项，也没有错误消息。关于为什么这样的基本功能被破坏的任何指示？版本信息：GNU objcopy (GNU Binutils) 2.24

人命令说下面。

. “富”然后...

我正在尝试将我的代码编译成原始二进制文件，并按照其他 SO 帖子（如this和this）的建议，我尝试了 objdump：

然后我试图确保这是否有效：

显然有些不对劲。我用 gcc 交叉编译的结果对此进行了检查，结果很明显不正确。

我很难在 Linux 上从剥离的二进制文件中生成 breakpad 符号。

我编译：

还有一些 C++ 文件。

然后我链接到：

最后将调试信息剥离到 .debug 文件中：

生成的二进制文件可以使用带有完整符号信息的 GDB 进行调试。它包含一个.gnu_debuglink引用foo.so.debug（无目录路径）的部分，这是正确的。

但是，dump_syms 似乎并没有关注该链接，即使此补丁中正在编辑的代码强烈建议它应该. 我在标准错误中得到这个输出：

生成的符号文件为 2MB，无论该.gnu_debuglink部分是否存在于 ELF 中。当将此 2MB 符号文件与 minidump_stackwalk 一起使用时，堆栈帧上会出现错误的函数。当我dump_syms在带有嵌入符号的二进制文件上运行时，输出文件为 9MB，并且堆栈帧是正确的。

我究竟做错了什么？

我有一个使用 g++ 2.96 版构建的库文件。该库的源代码不可用，也没有原始开发人员的支持。

我想使用最新的 g++ 版本（比如 4.x）将它与我的应用程序链接起来。据我了解，自 gcc veriosn 3.3 起，名称修饰方案已更改。这就是新链接器无法识别旧 lib 文件中的符号的原因。

我在网上做了一些研究，研究了 objcopy、objdump、c++filt 和 nm 等工具，并试图手动查找和解开 lib 文件中的符号，但无济于事。

那么，有没有办法（或工具）将我的旧二进制 lib 文件转换为新的名称修改方案，以便我可以使用更新的编译器链接它？

我有一个 ELF 32 位 x86 文件，其中包含一个.eh_frame部分，尽管我尝试¹删除它。

我想删除该.eh_frame部分，而不触及其他部分中的任何符号，包括未使用的符号。

strip似乎没有选项--remove-only，它总是最终修改其他部分。

如何在不修改文件中其他任何内容的情况下删除单个 ELF 部分？

¹正如其他问题中所建议的那样，我尝试了 的几种变体gcc-3.4.3 -fomit-frame-pointer -fno-exceptions -fno-asynchronous-unwind-tables -fno-unwind-tables，但该.eh_frame部分始终存在。这可能是因为我必须使用旧的 GCC（3.4.3）......源文件本身没有任何特殊内容可能需要这些部分：int main() { return 0; }.