4

私が作成した小さなプログラムには、バイナリ自体に含めることを好む多くの小さなビットマップとサウンド クリップが含まれています (いずれにしてもメモリ マップが必要です)。MS PE/COFF 標準には、適切なファイル システムのような階層を持つリソース (.rsrc セクション) を含める方法に関する特定の説明があります。私は Linux ELF 仕様でそのようなものを見つけていません。したがって、これらのリソースを自由に含めることができると思います。

私が達成したいのは、すべてのリソースを 1 つの ELF セクションに含め、各リソースの先頭にシンボリック名を付けることができるようにすることです (C コードからそれらをアドレス指定できるようにするため)。私が今行っているのは、次のレイアウトを持つ小さな NASM ファイルを使用することです。

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

これを、C コードとリンクできる ELF オブジェクトに簡単にアセンブルできます。ただし、コードがプラットフォームに依存するようになるため、アセンブリの使用は嫌いです。

同じ結果を達成するためのより良い方法は何でしょうか?

この質問はすでにstackoverflowで尋ねられていますが、提案された解決策は私の場合には当てはまりません:

  • ここで提案されている解決策: C/C++ with GCC: Statically add resource files to executable/library リソースを C コードに 16 進配列として含めることは、コードとデータが 1 つのセクションに混在するため、実際には役に立ちません。(さらに、リソースが配列に変換されるとリソースをプレビューできないため、実用的でもありません)
  • すべてのリソースでの使用objcopy --add-sectionは機能しますが、すべてのリソースは独自のセクション (ヘッダーなどを含む) を取得します。約 120 個のファイル (それぞれ +/- 4K) を含める必要があるため、これは少し無駄に思えます。
4

2 に答える 2

2

ELFファイルはデフォルトでそれらを分割するため、hexarrayを使用するとデータとコードが混在すると言うのは間違っています。特に、hexarrayを定数配列として定義すると、.rodata. の詳細については、私の古い投稿を参照してください.rodata。

でリソースを追加するとobjcopy、オブジェクト ファイルに複数のセクションが作成されますが、それらはすべて出力実行可能ファイルにマージされる必要があります。関連トピックに関する別の投稿。

実際のバイナリ ファイル (PNG など) から ELF に移行する場合の別の方法として、 ldscriptsを使用できます。これにより、任意のセクション/シンボルを使用して ELF ファイルを作成し、ファイルからデータを読み取ることができます。ELF ファイルを作成するには、カスタム ルールが必要です。

実際、この種のリソース管理が ELF であまり使用されていないことに驚いています。特に、多くの小さなファイルの場合、マップするファイルが多数ではなく 1 つしかないため、ファイルシステムのパフォーマンスが非常に迅速に向上するためです。

于 2014-08-01T11:37:33.660 に答える
0

リソースが大きすぎない場合は、たとえば unsigned char 配列として C/C++ ソース コードに変換できます。その後、それらにグローバル変数としてアクセスし、通常のソース コードのようにコンパイルおよびリンクできます。

于 2016-10-08T02:55:11.893 に答える