クライアントアーキテクチャ用のGNUアセンブラのポートを開発しています。現在直面している問題は次のとおりです。
命令のイミディエートオペランドが複数の再配置可能シンボルを含む式である場合、elf形式の出力ファイルでどのように処理されますか。そのような場合に生成される移転情報はどうなりますか?
例えば:
j label1 + label2
label1とlabel2が再配置可能セクションで定義されている場合、それらは同じセクションまたは異なる再配置可能セクションである可能性があります。
ELF は命令そのものを知りません。命令内のシンボル オフセットの特定のエンコーディングを認識します。アセンブラでは、命令のその部分に適切にパッチを適用するために、対応する [address,type,symbol] トリプレットをそれぞれ持つ 2 つの再配置レコードを出力する必要があります。リンカは、これらの 2 つのレコードが同じ命令を指していることを認識しているとは限りません。
ELF の再配置タイプは完全に CPU 依存 (より正確には ISA 依存) であるため、新しいアーキテクチャに必要な再配置を自由に定義できます。
命令エンコーディングの詳細がなければ、より具体的にすることは困難です。
私はELFについてジャックを知っていて、リンクについては少しだけ知っていますが...
各オペランドは、オペランドが 1 つしかない場合と同じように処理されることを期待しています。
OTOHの問題jは、ラベルの場所に応じてフォーマットが変わるということでしょうか? もしそうなら、リンカーはそのようなことをするほど賢くないので、あなたは沈んだと思います(ADAビルドシステムIIRCはほとんどのものよりも賢いかもしれないので、それを見るかもしれません.)
再配置が必要な命令ごとに、アドレスごとに 1 つのエントリが必要です。
Objdump は、実行可能ファイルまたはオブジェクト ファイルの再配置テーブルを表示できる可能性がありますが、フラグについてはわかりません。
私の提案は、クライアント アーキテクチャと同様のことを行う x86 (または他の CISC) 命令を掘り下げて、アセンブル/リンクしたときにどのような再配置が生成されるかを確認することです。