That the data gets put in the resource table, not one of the main sections. You can actually embed files via Windows. The _size symbol is particularly bizarre, since it's a length exposed asĪ symbol's address, not a variable.
Probably best just to use uint8_t and cast to void*. Doing so generates an annoying warning which can't beĭisabled. This is invalid in ANSI C, though youĬan do it in GCC. This is a curious case where declaring an extern void variable and taking You should access them with something like: extern uint8_t _binary_ FILENAME_start Important: These symbols represent the start and end addresses of the data. Some examples I've seen use asm("") to override the symbol names like so: extern uint8_t _binary_ FILENAME_start asm("_binary_ FILENAME_start") You might have to use extern "C" for the declarations if you're usingĬ++. data=.rodata,alloc,load,readonly,data,contents Pay attention to in which section the data is placed.įor objcopy, you can customize this with -rename-section. Used, so the input filename and the desired symbol name must match. GNU's objcopy does not appear to have any way to override the symbol names
in the input filename are converted to _. The symbols exported by such tools may vary. Reveals tools to generate both COFF and OMF object files are available.Ĭreating an object file with a single symbol isn't too difficult, so youĬan also construct such a tool yourself without too much difficulty. Again, thereĪppear to be a lot of tools going by these names. Ld has the advantage that it doesn't require you to explicitly specify theįor Windows, look for tools named bin2coff or bin2obj. objcopy -I binary -O elf32-i386 -B i386 file.bin file.o The disadvantage is that the tool is then platform-dependent. These skip the C source stage by producing an object file directly.
0 kommentar(er)
