問題タブ [relocation]

私はarm9プロセッサに基づくプロジェクトに取り組んでいます。オペレーティングシステムなしでベアメタルのみを使用しているため、残念ながら、共有ライブラリ/ダイナミックローダーはまだサポートされていません。

メインアプリケーションから関数を呼び出すこともできるSDカードなどからライブラリをロードできるようにしたいと思います。

私の最初の試みはリンカーオーバーレイ機能（特定の絶対位置のセクションにライブラリを配置する）を使用することでしたが、前述のようにメインアプリ関数を呼び出す際の問題があります->メインアプリケーションを変更するたびに、ライブラリを再コンパイルする必要がありますコールバックできるようにします。

これによると、私は自分のダイナミックローダーを作成する必要があると思いますが、私はこの分野の初心者です。誰かが私にそれをどのように扱うか、またはそのようなプロジェクトを始める方法の例を教えてもらえますか？arm-elfターゲットにはgccを使用しています。

Janに関して

これが私の目標です。Linux でソフトウェアを開発し、ソース コードなしで配布する必要があります。アイデアは、実行可能ファイルを実行するために必要なすべてのアイテムを含む zip ファイルを作成することです。ユーザーが zip をダウンロードして展開し、ダブルクリックすると、Linux ベースのマシンでソフトウェアが起動します。説明しない動機については、deb/rpm/etc またはインストーラーを使用できません。

sw には次の依存関係があります。

1. いくつかのライブラリ (OpenCV に依存する自分で作成)、g++ でコンパイル、.a ファイル (つまり、静的ライブラリ) を作成
2. いくつかの依存関係を持つ共有ライブラリ内の OpenCV

プログラムを gcc でコンパイルし、次のようにリンクします。

それから私は：

./lib にリストされているすべてのライブラリをコピーし、.zip を作成します。

zip を別のマシンにコピーすると、リストされている依存関係ldd my_exeが満たされ、正しく ./lib を指していますが、プログラムを起動すると、次のエラーが発生します。

どうしたの？私の間違いはどこですか？

いくつかの追加情報:

私はgcc 4.4.5、カーネル2.6.35 SMP、64ビットのUbuntuを使用しています。私が試したマシンも 64 ビット SMP カーネル 2.6 です。

以前objdump -x ...は、PE ファイルのセクションをチェックしていました。

約 90,000 行の reloc エントリがあります。

ほとんどの PE ファイルの大部分のスペースが上記のような reloc エントリで構成されているというのは本当ですか?

それらのエントリは何のためですか?

アップデート

上記のように再配置エントリがどのように機能するかを説明できる人はいますか?

Linux で cpp コードをコンパイルしようとしましたが、次のエラーが発生しました。

私の OS: Ubuntu 10.10
g++: gcc バージョン 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
以前にこのエラーに遭遇したことがありますか? ありがとう。

チェン

64 ビット FreeBSD で C アプリケーションをコンパイルしようとすると、次のエラーが発生しました。

再配置 R_X86_64_32S は、共有オブジェクトを作成するときに使用できません。-fPIC で再コンパイル

R_X86_64_32S移転とはR_X86_64_64？

エラーについてグーグルで検索しましたが、考えられる原因です-R_X86_64_32Sが実際に何を意味するのか誰かが教えてくれれば幸いです。

GNU ld 2.21 で Debian/Linux x86_64 を実行しています。

簡単に言えば、リンクすると

動作しますが、リンクすると

文句を言う

私は実際にこの方法でコードをコンパイルしようとしているわけではありませんが、ライブラリが存在するかどうかを確認する他の誰かのテストが機能しない理由を理解しようとしています。（したがって、何が起こっているのかよくわかりませんld...通常はGCCを使用してリンクします）

再配置可能な方法でリンクするように指示ldすると、突然ライブラリが見つからなくなるのはなぜですか? 存在することをテストしたいだけなら-lm、他に何をすべきですか

ライブラリを見つけるように？

私が扱っているソースを見たい場合は、https ://github.com/jeremysalwen/ESPS からダウンロードできます (最初のコミットは元のソース コードであり、その後のコミットは変更であることにご注意ください)。個人で作っています。）

Linux マシンで ImageMagick をクロスコンパイルしようとしています。ツールチェーンに付属する libstdc++.a は、fPIC でコンパイルされていません。代わりにsoファイルを使用したいと思います。ただし、libtool は libstdc++.a を (アーカイブ全体として) リンクし続け、再配置エラーが発生します。他のライブラリでも同じ問題が発生しました。何か案は？

共有ライブラリの再配置を調査していて、奇妙なことに遭遇しました。次のコードを検討してください。

で非PIC共有ライブラリにコンパイルしgcc -sharedます。x86で実行されている32ビットのUbuntuでこれを行います。

結果には、 in.soへの呼び出しの再配置エントリがあります。onの出力は次のとおりです。ml_util_funcml_func2objdump -dR -Mintelml_func2

命令のR_386_PC32再配置に注意してください。call

さて、私の質問は、なぜこの移転が必要なのですか? e8x86では「相対呼び出し...」でありml_util_func、同じオブジェクトで定義されているため、リンカーは動的ローダーに任せることなく、それと呼び出しの間の相対オフセットを計算できますか?

興味深いことに、ml_util_funcが宣言されている場合static、再配置はなくなり、リンカーはオフセットを正しく計算して挿入します。ml_util_funcリンカーがそれについて怠惰になるのは、エクスポートされていることについて何ですか?

PS: ロード時の再配置を理解するために、意図的に非 PIC コードで遊んでいます。

そのため、x86-64 には RIP 相対アドレッシングがあり、PIC コードの記述が容易になり、再配置の必要性がはるかに少なくなります。x86-64 ではなぜ再配置が必要なのですか? 何の機能ですか？試してみることはできますobjdumpが、どの C/C++ コード パターンをコンパイルして確認すればよいでしょうか?

メインプログラムを独自のイメージベースの非常に高い位置にリベースした後。

読み込まれる dll が 0x400000 に読み込まれることを保証するにはどうすればよいですか

0x400000 ではなく常に 0x460000 を取得します

dll の最初の命令を 0x401000 から開始する必要があります。以前は、リベースする前に 0x600000 で開始していました。

リンカがリベースするコマンドは

そのため、0x400000 は実際には現在無料ですが、デフォルトでは使用されません。そのため、再配置する必要がある場所に制御できます。多分いくつかのWIN32API？