4

私は最近、低レベルのCSマテリアルを（再学習して）いて、バッファオーバーフローを調査しています。8バイト配列の基本的なCプログラムを作成しましたchar buffer[8];。次に、GDBを使用してプログラムを調べて分解し、実行を進めました。私はUbuntuの64ビットバージョンを使用していますが、8バイトのchar配列が実際にはメモリ内の16バイトで表されていることに気付きました。上位ビットはすべて0です。

たとえば0xDEADBEEF 0x12345678、8バイトの配列を表すと予想されるのではなく、実際にはのようなもの0x00000000 0xDEADBEEF 0x00000000 0x12345678です。

私はグーグルを実行し、GCCにプログラムを32ビットプログラムとして（-m32フラグを使用して）コンパイルさせることができました。これにより、通常どおり8バイトが期待されていました。

私は、8バイトの文字配列が64ビットシステムで16バイトで表される理由について明確な説明を探しています。最小ワードサイズ/アドレス指定可能な単位が16バイト（64ビット）であり、GDBが8バイトのワードサイズに基づいて単純に印刷しているためですか？

これが明確であることを願っていますが、説明が必要な場合はお知らせください。

4

1 に答える 1

6

64ビットシステムは、すべてのメモリを16バイト境界にアラインメントするように調整されています（16バイトスタックアラインメントはSystem-V ABIの一部です）。スタック割り当てには、2つの部分があります。まず、スタック自体をアラインメントする必要があります。次に、割り当てはその配置を維持しようとします。

これは、8バイト配列がスタック上で16バイトになる理由、2つの8バイトqwordに分割される理由についての最初の部分を説明しています。コード（アセンブリまたはC）このバッファの使用に関して。そして、mingw64を使用してこれを複製しようとすると、16バイトの配置が提供されますが、表示されている面白いレイアウトは提供されません。

もちろん、ASMの欠如に起因する他の可能性は、GDBが実際には2xDWORDであるにもかかわらず2xQWORDを表示していることです（つまり、p/x (char[8])コンテンツをダンプするために使用してみてください...）。

于 2013-01-22T06:50:30.683 に答える