gcc 的 objectcopy 创建的符号宽度答案

【问题标题】：Width of symbols created by gcc's objectcopygcc 的 objectcopy 创建的符号宽度
【发布时间】：2014-11-24 11:30:42
【问题描述】：

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

我正在像这样使用 objcopy：

arm-none-eabi-objcopy.exe -I binary -O elf32-littlearm -B arm --rename-section .data=.rodata input.zip input.zip.o
arm-none-eabi-nm.exe -S -t d input.zip.o
00006301 R _binary_input_zip_end
00006301 A _binary_input_zip_size
00000000 R _binary_input_zip_start

我需要知道 _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

【问题讨论】：

我会在 hexdump 周围使用一些脚本来创建一个包含 const char zipcontent[] =...; 的大 C data.c 文件，然后链接 data.o。无需使用objcopy 技巧。
@BasileStarynkevitch 是的，我们曾经使用它，但是生成的 .c 文件需要添加到 SVN，因为构建服务器不会首先运行。（它首先查找构建索引所需的文件，然后运行“预构建”命令（创建所述 .c 文件），然后由于所述文件在预构建之前不存在而出错）。但是在 SVN 中生成也很烦人。
我不确定，但您可以使用 objdump 读取值。我在你的问题中遗漏了一些重要的东西？
不，objdump 也没有指定它们变量的类型。我只想知道它们是否应该读作 uint8_t[]、uint16_t[]、uint32_t[]、void[]。软件通过用 start 减去 end 来获得字节数量并以每个字节 (uint8_t) 为基础读取它就可以正常工作。我只是想知道指定正确的“外部”类型的基础类型。

标签： c gcc objcopy

【解决方案1】：

我不确定这是否可行，但请尝试将选项 --sort-size 添加到 arm-none-eabi-nm。这应该通过将符号与上面的下一个符号进行比较来按大小对符号进行排序。结合 -S 选项，它应该打印一个大小。希望这能帮助您推断出它们的宽度。

您使用的是什么 ARM micro？ 32 位是一个不错的猜测，但也有例外。如果您碰巧使用德州仪器的部件，我可以提供更多帮助。我手头没有可以测试的 ARM 项目，但值得一试。如果这不起作用，我会继续挖掘。

来源：我的知识，并通过http://manned.org/arm-none-eabi-nm仔细检查

【讨论】：

使用 NXP 32 位 arm 处理器。可悲的是，添加 --size-sort（不是 --sort-size）会一起删除输出。