問題タブ [elf]

libfoo.so.1に依存するライブラリがあるとlddしlibbar.so.1ます。ただし、libbar.so.1現時点では利用できません。libfoo.so.1私のアプリは、まったく必要のない関数を呼び出す必要がありlibbar.so.1ます。

をロードし、関数シンボルを解決してから、依存関係を満たさlibfoo.so.1ずに呼び出す方法はありますか? libbar.so.1「やっていることはわかっているから、もうやらせて」というケースです。RTLD_LAZY フラグを試しましたが、シンボルをロードしないlibbar.so.1前にライブラリをロードしようとします。

編集

これが正確な状況です。

プレイヤーは 3 人です。

• libbar.so.1LD_LIBRARY_PATHまたは以外のパスldconfigにあり、依存関係がすべて解決されている共有ライブラリ
• libfoo.so.1は、 とは異なるディレクトリにある共有ライブラリですが、libbarに依存していlibbarます。実行時に、libfooを見つける場所がわかりますlibbar。
• Applibfoo、実行時のある時点でロードする必要があるバイナリ アプリケーション。

Appを見つける場所はわかりませんがlibbar、知っていることはlibfoo知っています。私が達成しようとしているのは、すべての依存関係を最終的に解決し、すべての人を幸せにするために、の現在の作業ディレクトリを の場所にlibfoo変更するだけの init 関数を持つことです。Applibbar

libfoo最終的にlibbarは、この init 関数ではなく、でものを呼び出す必要があります。シンボルは最終的に実際の関数に解決する必要があるため、スタブの作成は機能しないと思います。

Linux システム (Fedora 9) の標準共有ライブラリはすべて、OSABI として ELFOSABI_NONE (0) を指定しています。

これは問題ありませんが、ELF ヘッダーで指定された OSABI が ELFOSABI_LINUX (3) である共有ライブラリをサプライヤから受け取りました。

これは、Linux システム用の共有ライブラリとしては不合理な値ではないように思えますが、私の他のすべてのライブラリとは異なる値です。私の他のライブラリの場合、これは「ELFファイルOS ABIが無効です」というエラーで失敗します。

FreeBSD ユーティリティbrandelf.cをコンパイルし、それを使用して OSABI タイプを 0 に変更したところ、ライブラリは他のすべてのもので正常に動作するようになりました。

私はただ疑問に思っています - なぜこのライブラリは ELFOSABI_LINUX としてマークされていると思いますか? おそらく、彼らは別のシステムでクロスコンパイルし、gcc フラグを指定して、この値を ELF ヘッダーに設定したのではないでしょうか? 同様のことを達成しようとしましたが、適切な gcc フラグを特定できませんでした。

この特定のサプライヤは多くの手を差し伸べないと何もしないので、考えられる原因を知りたいです。「あなたはおそらく X を行っていますが、これはあなたのライブラリを変更する必要があることを意味します。それらの配達を受け取った後」。

つまり、単一のバイナリ ファイルを Win32 と Linux i386 の両方で実行できますか?

共有オブジェクトを生成できるコードジェネレーターへのインターフェイスを作成しました。セクションヘッダーテーブルのサポートを実装する必要はありませんが、ELFファイル形式の大部分の複雑さが残っているためです。

GNU ldは、共有オブジェクトに対してリンクするためにセクションヘッダーを使用します。これは、セクションヘッダーのない共有オブジェクトに対してgccリンクを配置しようとすると、ライブラリにシンボルが存在していてもldがシンボルを見つけられないため、失敗することを意味します。

特定のシンボルが見つからない場合でも、リンクを成功させるためにコンパイラーをだますために使用できるトリックはありますか？

トラブルについての説明は次のとおりです。

私は用語を少し混乱させています。

リンカーへの入力として与えられるファイルはObject Fileと呼ばれます。リンカーはイメージ ファイルを生成し、それはローダーによって入力として使用されます。

「MS PE&COFF仕様書」より頂きました。

Q1. Binary Image画像ファイルは、Binary Fileまたは単にとも呼ばれますBinary。右？

Q2. したがって、上記の用語によると、PE/ELF/COFF はイメージ ファイルの形式であり、オブジェクト ファイルではありません。右？しかしhttp://www.sco.com/developers/gabi/latest/ch4.intro.htmlは言う

この章では、ELF (Executable and Linking Format) と呼ばれるオブジェクト ファイル形式について説明します。オブジェクト ファイルには、主に 3 つのタイプがあります。

• 再配置可能ファイルには、他のオブジェクト ファイルとリンクして実行可能ファイルまたは共有オブジェクト ファイルを作成するのに適したコードとデータが含まれています。

• 実行可能ファイルには、実行に適したプログラムが含まれています。このファイルは、exec(BA_OS) がプログラムのプロセス イメージを作成する方法を指定します。

• 共有オブジェクト ファイルには、2 つのコンテキストでのリンクに適したコードとデータが含まれています。まず、リンク エディタ [ld(BA_OS) を参照] は、共有オブジェクト ファイルを他の再配置可能共有オブジェクト ファイルと一緒に処理して、別のオブジェクト ファイルを作成します。次に、ダイナミック リンカーは、プロセス イメージを実行可能ファイルやその他の共有オブジェクトと組み合わせて、プロセス イメージを作成します。

矛盾して、彼はオブジェクト ファイルとイメージ ファイルの両方が ELF 形式であると言っています。彼はオブジェクト ファイルとイメージ ファイルをまったく区別しておらず、一般的にオブジェクト ファイルと呼んでいます。それは間違っていませんか？

Q3. PEはCOFFから派生したものだと知っています。しかし、なぜ Microsoft の PE フォーマットの仕様は、Microsoft Portable Executable および Common Object File Format Specification と名付けられたのでしょうか。彼らはまだCOFFをサポートしていますか? もしそうなら、どのOSで？PE はずっと前に COFF に完全に取って代わったと思っていました。

実行すると、プログラムは仮想アドレス 0x80482c0 から実行を開始します。このアドレスは、プロシージャーではなく、リンカーによって作成されたmain()という名前のプロシージャーを指しています。_start

これまでの私の Google の調査では、次のような (漠然とした) 歴史的な憶測にたどり着きました。

0x08048000 はかつて、カリフォルニア州サンタクルーズのグループによって公布された *NIX から i386 への移植で、0x08048000 付近から 0x08048000 付近から下方に成長したスタックであったという伝承があります。これは、128MB の RAM が高価であり、4GB の RAM は考えられない時代でした。

誰でもこれを確認/拒否できますか?

ARM ELFを使用してコードを追跡する方法は？どのツールを使用する必要がありますか？

多くの PE ファイル ブラウザがあります。あなたが興味を持っているなら、ここに良いもののリストがあります：

PE ファイル形式のビューア:

• PE エクスプローラーhttp://www.pe-explorer.com/
• PE ビュー: http://www.magma.ca/~wjr/
• PEBrowse プロフェッショナルhttp://www.smidgeonsoft.prohosting.com/pebrowse-pro-file-viewer.html
• PE Browse Professional Interactive - http://www.smidgeonsoft.prohosting.com/pebrowse-pro-interactive-debugger.html

私はまだ Windows で作業しており、ELF ファイルを表示したいと考えています。ツールはありますか？私はググっていますが、今まで見つけられませんでした。

関数のトレーサーを少し書きたいと思います。私はptraceを使っています。

CALL命令を見たときに、アドレス呼び出しに相当する関数名を表示したい。

私のトレーサーは、絶対アドレスを持つシンボルで動作します (シンボルはメイン バイナリで定義されます)。しかし、共有ライブラリの関数の仮想メモリ内の絶対アドレスを取得する方法がわかりません。たとえば、libc の関数の呼び出しを検出します。

共有ライブラリ内の関数のアドレスがファイルに対して相対的であることに気付きました。

次の式は良いですか？

共有ライブラリからシンボルの絶対アドレスを取得するにはどうすればよいですか?

関数のトレーサーを少し書きたいと思います。私はptraceを使っています。私はubuntu x86_64を使用しています。共有ライブラリ関数 ( など) のアドレスを見つけたいprintf。

しかし、Global Offset Table についていくつか問題と質問があります。次のコードがあります。

readMemoryトレースされたプロセスのメモリで読み取られた関数。

を読み取ろうとするとlinkList->l_ld、動的セクションを指していないようです。

コードが正しいかどうかわかりません。を使用するreadelfと、GOTセクションのアドレスが私のプログラムが見つけたものと同じです。

GOT セクションの最初のオフセットのみを読み取る必要がありますか? GOT エントリ ポイントには、struct link_map?を指す絶対アドレスのみが含まれます。

ありがとうございました。