Bri*_*ian 9 gcc arm cortex-m3 ld
我想链接原始二进制数据.我想把它放在一个特定的地址,或者把它链接到我在代码中定义的符号(例如char*mydata).因为它不是一个obj文件,所以我不能简单地将它链接起来.
类似的帖子(包含GNU ld链接器脚本的二进制文件)建议使用带-B bfdarch选项的objcopy .objcopy以"archictecture bfdarch unknown"作为回应.
另一个答案建议将对象转换为自定义LD脚本,然后将其包含在主LD脚本中.在这一点上,我可能只是使用一个C包含文件(这就是我现在正在做的)所以我宁愿不这样做.
我可以使用objcopy来实现这一目标,还是有其他方法?
Fra*_*kH. 13
以下示例适用于我:
$ dd if=/dev/urandom of=binblob bs=1024k count=1
$ objcopy -I binary -O elf32-little binblob binblob.o
$ file binblob.o
binblob.o: ELF 32-bit LSB relocatable, no machine, version 1 (SYSV), not stripped
$ nm -S -t d binblob.o
0000000001048576 D _binary_binblob_end
0000000001048576 A _binary_binblob_size
0000000000000000 D _binary_binblob_start
Run Code Online (Sandbox Code Playgroud)
也就是说,不需要为二进制数据指定BFD arch (它只对代码有用/必要).只需说"输入是二进制","输出是......",它就会创建文件.由于纯二进制数据不是特定于体系结构的,所以您需要告诉它的是输出是32位(elf32-...)还是64位(elf64-...),以及它是小端/ LSB(...-little如ARM/x86)还是大端/ MSB (...-big例如,在SPARC/m68k上).
编辑:
澄清以下选项objcopy:
-O ...选项控件的用法:
-B ...选项的使用控制ELF文件将请求的体系结构你必须指定,-O ...但是-B ...是可选的.通过一个小例子可以很好地说明差异:
$ objcopy -I binary -O elf64-x86-64 foobar foobar.o $ file foobar.o foobar.o: ELF 64-bit LSB relocatable, no machine, version 1 (SYSV), not stripped $ objcopy -I binary -O elf64-x86-64 -B i386 foobar foobar.o $ file foobar.o foobar.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped
即只是输出格式说明符elf64-x86-64不会将生成的二进制文件绑定到特定的体系结构(这就是为什么file说no machine).如果-B i386这样做的用法- 在这种情况下,你被告知这是现在AMD x86-64.
这同样适用于ARM; -O elf32-little与-O elf32-littlearm -B arm之前的情况相比,你ELF 32-bit LSB relocatable, no machine, ...在后者中会有一段时间,这将是一个ELF 32-bit LSB relocatable, ARM....
这里也有一些相互依赖; 你必须使用-O elf{32|64}-<arch>(不是通用的elf{32|64}-{little|big})输出选项才能-B ...识别.
请参阅objcopy --infobinutils可以处理的ELF格式/ BFD类型列表.
另一种方法可能是使用xxd.
xxd -i your_data your_data.c
Run Code Online (Sandbox Code Playgroud)
在文件中,您将获得两个符号unsigned char your_data[]和unsigned int your_data_len.第一个将是包含您的数据的巨大数组,第二个将是该数组的长度.
编译创建的C文件可能需要花时间,因此如果您使用构建系统/ Makefile处理它,则可以正确避免不必要的重新编译.
xxd应该是Linux发行版的vim(vim-common)包的一部分.