4

A small program I made contains a lot of small bitmaps and sound clips that I would prefer to include into the binary itself (they need to be memory mapped anyway). In the MS PE/COFF standard, there is a specific description on how to include resources (the .rsrc section) that has a nice file system-like hierarchy. I have not found anything like that in the Linux ELF specification, thus I assume one is free to include these resources as seemed fit.

What I want to achieve is that I can include all resources in only one ELF section with a symbolic name on the start of each resource (so that I can address them from my C code). What I am doing now is using a small NASM file that has the following layout:

SECTION .rsrc
   _resource_1:
      incbin  "../rsrc/file_name_1"
   _resource_1_length:
      dw $-resource_1
   _resource_2:
      incbin  "../rsrc/file_name_2"
   _resource_2_length:
      dw $-resource_2
   ...

I can easily assemble this to an ELF object that can be linked with my C code. However, I dislike the use of assembly as that makes my code platform-dependent.

What would be a better way to achieve the same result?

This question has already been asked on stackoverflow, but the proposed solutions are not applicable to my case:

  • The solution proposed over here: C/C++ with GCC: Statically add resource files to executable/library Including the resources as hex arrays in C code is not really useful, as that mixes the code and the data in one section. (Besides, it's not practical either, as I can't preview the resources once they are converted to arrays)
  • Using objcopy --add-section on every resource works, but then every resource gets its own section (including header and all that). That seems a little wasteful as I have around 120 files to include (each of +/- 4K).
Community
  • 1
  • 1
billybob
  • 127
  • 5
  • 1
    The "__section" GCC keyword could be used with the proposed solution of including hex-arrays. By making the "array"-files depend on their binary "parents" in your build-environment, you'll still have the possibility of previewing the files. – S.C. Madsen Jan 07 '14 at 11:20

2 Answers2

2

You're wrong saying that using hexarrays mixes data and code, as ELF files will split them by default, in particular, if you define the hexarray as a constant array, it'll end up in .rodata. See an old post of mine for more details on .rodata.

Adding resources with objcopy should create multiple sections in the object file, but then they should all be merged in the output executable, although then you would have some extra padding almost certainly. Another post on a related topic.

Your other alternative if you want to go from the actual binary file (say a PNG) to ELF, you can use ldscripts, which allow you to build ELF files with arbitrary sections/symbols and reading the data from files. You'll still need custom rules to build your ELF file.

I'm actually surprised this kind of resource management is not used more often for ELF, especially since, for many small files, it'll improve filesystem performance quite quickly, as then you only have one file to map rather than many.

Diego Elio Pettenò
  • 3,152
  • 12
  • 15
0

If your resource is not too large, you can translate them into C/C++ source code, for example, as a unsigned char array. Then you can access them as global variables, and compile & link them like normal source code.

jiandingzhe
  • 1,881
  • 15
  • 35