Embedding binary in an elf using objcopy can cause alignment problems?

Question

There were several posts in stackoverflow and other places that described in detail how to embed binary drops in elf binaries.

Insert binary blocks using gcc mingw

and

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

- the most complete answers.

But there is a possible problem that no one mentions. Here quicky foo.txt is hidden for foo.o:

$ 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 ld .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 

Now, I really don't understand this release - is there any documentation for this stuff ??? I guess most of this is pretty obvious, "g" is global, and "l" is local, etc. Etc....

What is allocated to align the .data segment set to 0. Does this mean that I think it means? i.e.: when it comes to links, the linker will be "oh yes, wherever ..."

If you insert char data or work on x86, then you will never notice. But if you insert int data or, as I do, 16 and 32 bit data in ARM, then you can get the alignment trap at any point.

I get the feeling that this means that either objcopy needs another option to indicate the alignment of the binary blob, or it is broken, and you should not use this method at all.

Answer 1

To answer my own question, I would say that objcopy is broken in this case. I believe using assembly is probably the best way to go here using Gnu as. Unfortunately, now I'm not sure about Linux, so I can’t check it correctly, but I will put this answer here if someone finds it or wants to check:

 .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: 

Underscore characters are a traditional way to annoy yourself with C / asm compatibility. In other words, they disappear with MS / Borland compilers for Windows.

Answer 2

Create the linker script "lscript.ld"

 MEMORY { memory : ORIGIN = 0x00000000, LENGTH = 0x80000000 } SECTIONS { .data (ALIGN(4)) : { *(.data) *(.data.*) __data_end = .; } > memory .text (ALIGN(4)) : { *(.text) *(.text.*) __text_end = .; } > memory _end = .; } 

Link your file:

 gcc -Wl,-T -Wl,lscript.ld -o linked_foo.elf foo.o 

Find all the extraneous things added to the link:

 objdump -x linked_foo.elf 

Objcopy again to remove excess material:

 objcopy --remove-section ".init_array" (repeat as necessary) --strip-all --keep-symbol "_binary_foo_txt_start" --keep-symbol "_binary_foo_txt_end" --keep-symbol "_binary_foo_txt_size" linked_foo.elf final_foo.elf 

This gives you an elf file with an alignment of 2 ** 2.