問題タブ [objcopy]

g++ でコンパイルすると、ほとんどの関数ごとに余分なセクションが作成されます。これは、実行可能ファイルで発生linuxしelf64ます。
例:

.text セクションが 1 つだけになるように、g++ に .text のすべてのコードを発行するように指示するにはどうすればよいですか

これは -ffunction-sections なしで発生します

そして、セクションはその後も残ります

==================================================

追加情報：

テキストファイル（またはその他のリソース）をバイナリに埋め込むことについて読んだことがありますが、次のようにしています：

ただし、チュートリアルとは異なり、次の応答が返されます。

この例では i386 を使用していますが、そのようにすることもできないため、これも問題ではないようです。

objcopy に、それがテキスト ファイルであり、有効な互換性のあるバイナリではないという事実を無視させて、バイトごとにプログラムにコピーする方法はありますか?

QEMU でエミュレートされた MIPS Malta ボードのブート コードを書き込もうとしています。

私が理解しているように、Malta ボードは 4MB のコードをフラッシュから物理 RAM の特定の位置 (0x1fc00000、MIPS プログラム アドレス空間の 0xbfc00000: MIPS32 リセット割り込み位置) にロードします。この場所に読み込まれて実行されるコードを作成しようとしています。

私は永遠にループする単純なアセンブリプログラムを持っています:

これを GNU アセンブラでアセンブルすると、このコードを含む .text セクションを含む ELF ファイルが得られます。objdump を使用して逆アセンブルします。

リンカー スクリプトを使用して、.text セクションを 0x8fc00000 に再配置できます。

ELF ファイルには実行不可能な他のセクション、ELF ヘッダーなどが含まれているため、objcopy を使用してテキスト セクションのみをダンプします。

ただし、分岐オペランドは依然として相対であるため、結果のコードは絶対アドレス指定を使用せず、0x8fc00000 ではなく 0x0 に分岐します。

出力で相対アドレスを絶対アドレスに解決する objcopy または ld へのフラグを無駄に検索しました。セクションの開始アドレスを操作するための objcopy フラグがありますが、これらは出力形式のオフセット テーブルを変更するだけであり、バイナリ出力には影響しないと思います (明らかにそのようなテーブルはありません)。

これまでに見つけた唯一の回避策は、アセンブリ ソースに .org ディレクティブを追加することです。

これにより、当然のことながら、前にゼロが埋め込まれた約 2 GB のファイルが生成されますが、切り捨てることができる絶対アドレス指定のコードが生成されます。

これを行う正しい方法はありますか？

Wine/Darling やその他の互換性レイヤーについては知っていますが、(たとえば) 次の方法で可能かどうか疑問に思っていました:
1. OS X で単純な hello_world.c プログラムをビルドします
。マシン コードを Linux 実行可能ファイルにコピーし、OSX libc への呼び出しを glibc への呼び出しに置き換えます。他の OSX ライブラリに動的にリンクされた別の実行可能ファイルである場合は、ライブラリをコピーします。
3. プログラムが動作することを前提として、Linux でプログラムを実行します。
例hello_world.c：

データを含む位置相対コードを書きたいと思います。

つまり、printf の絶対アドレスを取得し、単純な文字列を出力する関数です。

パラメータ-fPICを指定してarm-none-eabi-gccを使用して ELF をコンパイルすることで、これを達成することができました。問題は、 objcopyを使用して ELF ファイルをフラット バイナリに変換することです。

objcopyは文字列をファイルの先頭に配置するため、関数の最後に文字列を残す代わりに、データが位置に依存しなくなり、プログラム カウンターによってアドレス指定されます。

何か不足していますか？objcopy が位置に依存しないデータでフラット バイナリを作成することは可能ですか?

編集：

添付の画像で、文字列が関数の最後ではなく関数の上の絶対アドレスにあり、PC によって指されていることがわかります。