問題タブ [readelf]

実行可能ファイルから構造定義を抽出する必要があります。どうやってやるの？ELFを使用してそれを行うことができると読みましたが、これを行う方法がわかりません。ここで何か助けはありますか？

ELF内のシンボルテーブルを理解しようとしていたので、次のことがありました。

ELF 内の symtab をコンパイルしてチェックします。

私を本当に混乱させたのは、（インターネットから）「値」は各セクションのオフセットを意味し、「サイズ」はターゲットサイズを意味すると言いました。なぜそれらはすべてオフセット 00000000 で、一部はサイズ = 0 なのですか?

質問：

size=0 の場合、存在しないはずであり、ELF 内に情報を保持しても意味がないと思います。

たとえば、ソースファイル名「ac」を含む行「1」(私は「# Confused」とマークしました) には、Ndx=ABS および Name=ac の情報があります。このセクションのサイズが 0 の場合、ELF 内にどのように格納されますか? ? "ac" というファイル名を保存するには、少なくとも 3 バイトあるはずなので、サイズは >=3 にする必要があります。

ELF ファイルの一部のセクション (.dynstr など) では、セクション ヘッダー テーブルの構造に書き込まれるオフセットは、「readelf -a」では報告されません。たとえば、オフセットは「0x0245」ですが、readelf はセクションのオフセットとして「0x0300」をレポートします。HexEditor を使用して、「readelf」によって返されるオフセットが間違っていることを確認できます。最初のいくつかのセクションでは、対応するオフセットとして readelf が報告しているものは正しいですが、いくつかのポイントはすべてのオフセットが間違っています。報告されたオフセットがファイルに書かれているものと異なる理由を知っている人はいますか? それとも readelf に関連するバグですか?

注：「objdump -h」を使用すると、readelf によって報告されたオフセットが間違っていることも確認できます

注 2 : 「readelf」によって返される一部のオフセットは、ファイル サイズよりもさらに大きくなります。

これは出力例または readelf です。

これは「objdump -h」出力です:

問題のシナリオ: 簡単に言えば、ターゲットにロードされた ELF ファイルからシンボル (およびその内容) を読み取る Trace32 コマンドはありますか? ELF ファイルのアプリケーション固有のデバッグ シンボルが ELF の「.noload」セクションの一部として作成される特殊なケースがあります。これは、シンボル/コンテンツが ELF ファイルの一部として存在することを意味します (readelf -a xxxx. elf_file_name) ですが、生成される最終的なバイナリ イメージの一部ではありません。つまり、ELF ファイルの「.noload」セクションは、ターゲット メモリにフラッシュされる xxx.bin を生成するときに取り除かれます。

• 「.noload」セクションのデバッグ シンボルは静的に割り当てられた値であり、これらの値は実行時に変更されません。
• 「.noload」セクションのデバッグ シンボル部分を読み取ろうとすると (バイナリにコンパイルして Trace32 にロードした後)、trace32 ポップアップ ウィンドウに「MMU 失敗」というフラグが表示されます。これは、trace32 がシンボルの内容をメモリから読み取ろうとしているが、アドレスがマップされているにもかかわらず、「.noload」セクションのシンボル部分がまったくロードされなかったため、アクセスできません。

任意の入力:
- ターゲット メモリからではなく、ELF ファイルからシンボル コンテンツを直接読み取ることができる trace32 コマンドのヘルプが必要です。
- また、練習用スクリプトで「readelf」を使用できるかどうかもわかりません。上記のクエリの解決策がない場合、この方向で何か助けはありますか?

register_tm_clonesderegister_tm_clonesRW セクションの終わりを過ぎたメモリ アドレスを参照しています。このメモリはどのように追跡されますか?

例:以下の例では、deregister_tm_clonesメモリ アドレス0x601077を参照していますが、最後に割り当てた RW セクションは から.bss始まり、0x601069サイズは であり、さらに0x7get が追加されています0x601070。したがって、参照は明らかにセクションに割り当てられたものを超えており.bss、ヒープスペースにあるはずですが、誰がそれを管理していますか.

参照はセクションの最後から始まることに注意してください.bss。gdb を使用して割り当てられたメモリを調べると、十分なスペースがあることがわかり、正常に動作しますが、このメモリがどのように管理されているかわかりません。

他のセクションでそれへの他の参照を見つけることができません。.bss 用にロードされたセグメントによって予約されたスペースもありません。

誰でもこれらの機能を明確にできますか? ソースはどこですか？トランザクションメモリに関するすべての参考文献を読みましたが、それらは実装ではなくプログラミングをカバーしています。もちろん、何も残らないことを除いて、このコードを削除するコンパイラオプションが見つかり-nostdlibsません。

これらはおそらくmallocの一部ですか？それでも、malloc、threading、または STM を使用していないコードについては、これらをコードにリンクする必要があることに同意するかどうかはわかりません。

gcc は Linux ELF にどのような機能を追加しますか?も参照してください。

詳細:

例えば：

各 DIE エントリの先頭には、 などの数字があり<0>ます<1>... これらの数字は何を意味するのでしょうか? 同じ番号は同じ DWARF タイプを示しているようです。たとえば、エントリ<1>がすべて (DW_TAG_base_type).

述語CMakeを使用して、で構築された Ubuntu システムにアプリケーションがあります。add_executableそれ自体は正常に動作しますが、共有ライブラリに通常適用されるreadelfものとして表示されます。DYN (Shared object file)

なぜこれが起こるのか誰にも分かりますか？