gcc - 使用objcopy将二进制嵌入到elf中可能会导致对齐问题？

Question

在 stackoverflow 和其他地方有很多帖子详细介绍了如何将二进制 blob 嵌入到 elf 二进制文件中。

Embedding binary blobs using gcc mingw

和

C/C++ with GCC: Statically add resource files to executable/library

是最完整的答案。

但是有一个可能的问题没有人提到。这是一个覆盖到 foo.o 的快速 foo.txt:

$ objdump -x foo.o 
foo.o:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         0000000d  00000000  00000000  00000034  2**0
                  CONTENTS, ALLOC, LOAD, DATA
SYMBOL TABLE:
00000000 l    d  .data  00000000 .data
0000000d g       .data  00000000 _binary_foo_txt_end
0000000d g       *ABS*  00000000 _binary_foo_txt_size
00000000 g       .data  00000000 _binary_foo_txt_start

现在，我并没有真正理解所有这些输出 - 有这些东西的文档吗？？？我想大部分都是很明显的“g”是全局的，“l”是本地的等等......

突出的是 .data 段的对齐设置为 0。这是否意味着我认为的意思？即:当涉及到链接时，链接器会说“啊，是的，无论在哪里......”

如果您嵌入字符数据或在 x86 上工作，那么您永远不会注意到。但是，如果您在 ARM 上嵌入 int 数据，或者像我正在做的那样，嵌入 16 位和 32 位数据，那么您可能会在任何时候遇到对齐陷阱。

我的直觉是，这意味着 objcopy 需要另一个选项来指定二进制 blob 的对齐方式，或者它已损坏并且您根本不应该使用此方法。

Answer 1

为了回答我自己的问题，我断言 objcopy 在这种情况下被破坏了。我相信使用汇编可能是使用 Gnu 作为这里的最佳方式。不幸的是，我现在没有 linux 机器，因此无法正确测试，但我会将这个答案放在这里，以防有人找到它或想要检查:

.section ".rodata"
.align 4 # which either means 4 or 2**4 depending on arch!

.global _binary_file_bin_start
.type _binary_file_bin_start, @object
_binary_file_bin_start:
.incbin file.bin

.align 4
.global _binary_file_bin_end
_binary_file_bin_end:

下划线是用 C/asm 互操作性惹恼自己的传统方式。换句话说，它们在 Windows 下随着 MS/Borland 编译器消失。