問題タブ [memory-segmentation]

一部の C コードを gcc でコンパイルすると、次のアセンブリ結果が表示されることがよくあります。

これは単純な関数のプロローグです。+19 行から、スタック プロテクターの値が gs:0x14 から取得されていることがわかります。私の質問は、gdb で gs:0x14 の実際の仮想アドレスを知ることはできますか? gs セグメント セレクターの値は GDT からのオフセットを示しますが、gdb などのユーザー レベルのプロセスは GDT 情報にアクセスできません。gdb または他のデバッガーを使用して gs セグメントのベースアドレスを特定するにはどうすればよいですか? これは不可能ですか？

前もって感謝します。

GDB を使用してプログラムをデバッグしているときに、x86-64 モデル固有のレジスタ、具体的には IA32_FS_BASE および IA32_GS_BASE を読み取る方法はありますか?

Intel の Pintool のような動的インストルメンテーション パッケージを使用するソリューションはあまり好ましくありませんが、それでも同様に高く評価されます。

私は c で vigenère アルゴリズムを実装しています。

残念ながら、プログラムをテストしているときに、セグメンテーション エラーが発生しました。Macでclangでコンパイルしています。

どうすればそのエラーを回避できますか?

ソースコード：

デバッグ出力:

よろしく

I Googled for a long time but I still don't understand how it works as most of the explanation are very technical and there are no illustrations to make it clearer. My primary confusion is that what is its'difference with virtual memory?

I hope this question will have a very good explanation here so that other people who ask the same question can find it here when they Google it.

メモリ セグメンテーションに関するウィキペディアの記事によると、x86 プロセッサはハードウェアでセグメンテーション境界チェックを行います。ソフトウェアで境界チェックを行うシステムはありますか? もしそうなら、どのようなオーバーヘッドが発生しますか? ハードウェアの実装で、ペナルティを回避するために境界チェックをスキップする方法はありますか (ペナルティがある場合)?

ELF32 バイナリにいくつかのカスタム コード変換を適用したいと考えています。最初に ELF ファイルを解析し、次に変換を適用します。その後、ELF セクションを新しい出力ファイルにまとめます。

変換の実装を開始する前に、ELF セクションを新しいバイナリ ファイルに書き戻すときに問題に遭遇しました。つまり、セクションを新しい ELF に書き込むときに、セクションを適切に配置する必要がありました。p_alignこの目的でプログラム ヘッダーからの値を使用しようとしましたが、正しくありません。p_offsetELF ファイルに書き込むときに使用する必要がある値のようですが、どのように計算されるかわかりません。

私が言いたいことの例を挙げましょう。次の単純な C コードがあります。

GCC 4.8.2 を使用して 32 ビット ELF 実行可能ファイルをビルドしました。次にreadelf -h a.out、この ELF32 バイナリのプログラム ヘッダーを出力したところ、次の出力が得られました。

この例を考えると、次の質問があります。

1. p_offset特定のセグメントの正しい値をどのように計算しますか? p_offsetそもそもどうやって計算したの？

2. p_align2 番目の LOAD セグメントがその値に関して位置合わせされていないのはなぜですか? 具体的には、なぜでは0x08049f08なくで始まるの0x08049000ですか?

3. p_offsetがより小さくないのはなぜですか? ELF ファイル内でこれに先行するセクションはオフセット0xf08で終了し、ファイルにはこのセクションとで始まる次のセクション ( ) の間に 2460 ゼロ バイトがあるからです。とにかく、これらのセクション間に 2460 のゼロ バイトがあるのはなぜですか?eh_frame0x56Cinit_array0xf08

「Test Drive III」を分解しています。1990年のDOSゲームです。*.EXE は MZ 形式です。セグメンテーションや DOS を扱ったことがないので、質問に答えていただければ幸いです。

1) ゲームのシステム要件には、プロテクト モードを備えた 286 CPU が記載されています。私の知る限り、DOS は 90% がリアル モード ソフトウェアでしたが、一部のアプリケーションはプロテクト モードに入ることができました。アプリがリアル モードでのみ CPU を使用していることを確認できますか? IOW、セグメント レジスタには、セグメント記述子へのインデックスではなく、セグメントの実際のオフセットが含まれていることが保証されていますか?

2）上記のシステム要件には、1 MBのRAMが記載されています。アドレス空間の最上位 384 KB が MMIO や ROM などのために予約されている場合、この量の RAM はどのようにアクセスされるのでしょうか? UMB (UMA の穴を使用して RAM にアクセスする) と HMA について聞いたことがありますが、それでも 1 MB の物理 RAM 全体にアクセスすることはできません。では、RAM の物理アドレスがたまたま UMA 用に予約されていたため、貴重な RAM が無駄になったのでしょうか? それとも、ゲームで LIM EMS や XMS などの松葉杖を使用するのでしょうか?

3) コードがセグメントの境界を越えると、CS は自動的にインクリメントされますか? たとえば、IP が 0xFFFF に到達すると、どうなるでしょうか。CS は、次の命令が実行される前に次のセグメントに切り替えますか? SSも同様です。SP が 0x0000 まで下がるとどうなりますか?

4) 実行可能ファイルの MZ ヘッダーは次のようになります。

なぜ移転情報がないのですか？アドレスの修正なしで実行することをどのように意味するのでしょうか? それとも、プログラム カウンター相対命令から構成される完全に位置に依存しないコードとして構築されていますか? ゲームには、MZ 実行可能ファイルでもあるチート ユーティリティが付属しています。はるかに小さい (8448 バイト - 1 つのセグメントに収まるほど小さい) にもかかわらず、再配置情報があります。

これにより、IDA はチートのコードを適切に逆アセンブルできます。しかし、ゲームの EXE には、明らかにたくさんの far ポインターがありますが、何もありません。

5) DOS には「セクション」のようなものさえありますか? つまり、データセクション、コード（テキスト）セクションなどですか？MZ ヘッダーはスタック セクションを指していますが、データ セクションに関する情報はありません。DOS プログラムでは、データとコードが完全に混在していますか?

6) EXE ファイルにスタック セクションがあるのはなぜですか? ゼロしかありません。「ここからスタックを開始する」とだけ言うのではなく、ディスク容量を無駄にするのはなぜですか? BSSセクションで行われているような？

7) MZ ヘッダーには、SS と CS の初期値に関する情報が含まれます。DSはどうですか？その初期値は？

8) MZ 実行可能ファイルの exe データの後に何がありますか? チートユーティリティには、実行可能ファイルの最後に 3507 バイト全体があり、次のようになります。

これはある種のデバッグ シンボル情報ですか?

よろしくお願いいたします。

たとえば、数千の要素を持つ int 配列があります。

と

上記の2つの方法、特にメモリ使用量の中括弧の値の違いは何ですか?

st_indices はプログラムが終了するまで (STACK)、dy_indices はdelete [](HEAP) 後に解放されることを知っています。それとも、スタックと .DATA セグメントに関する質問ですか?

グローバル配列の要素としてのみ割り当てられる特定のクラスがあります（ファイルへのハンドルの例を想像してください）。

C++ コンパイラ (g++ や clang など) をハックして、そのクラスがポインターをアドレスとしてではなくその配列内のインデックスとして発行および解釈するようにする必要があります。

つまり、インデックスを「this」ポインターとして受け入れるクラスのメソッドと、ポインターの代わりに配列内のインデックスを返すコンストラクターが必要です。

私は x86 アーキテクチャを使用して作業しているため、クラスのサイズが 1 2 4 または 8 バイトの場合、そのようなインデックスを「実効アドレス」に変換することは、アドレッシング モードの問題にすぎません。

ある種の「外部ポインタ」または同様のものを管理するために、そのような可能性がすでに存在している可能性があります。

私が知っていることは、次のように説明されている CLANG 内の機能です。

アドレス空間 #256 でポインターに注釈を付けると、X86 GS セグメント レジスタを基準にして生成されたコードになり、アドレス空間 #257 を使用すると、X86 FS セグメントを基準にします。これは非常に低レベルの機能であり、何を行っているかがわかっている場合にのみ使用する必要があることに注意してください (たとえば、OS カーネルで)。

次に例を示します。

https://clang.llvm.org/docs/LanguageExtensions.html#memory-references-to-specified-segments

これは相対性を解決できますが、アドレスに到達するためのインデックスの乗算は解決できません。しかし、オブジェクト コンストラクターから相対アドレスを取得するためにそれを使用する方法は明確ではありません。

質問は十分に明確ではないため保留されていますが、最終的に簡単な方法を使用してとにかく解決しました。これは、同じ質問を可能な解決策として理解するのに役立つ解決策のドラフトです（最後に到着しました）。

非常に複雑な問題が「単純な」十分な方法で解決できるのは奇妙に思えます。インデックスをオブジェクトとして使用できるため、これはまさに私が必要としていたソリューションです。

一般的に言えば、x86 のデータ セグメントはオーバーラップする可能性がありますが、スタックとデータ セグメントがオーバーラップする可能性があることはわかっています。