3

最近、YASM を使用して Intel x86-64 アーキテクチャのアセンブリ言語を学び始めました。本で提案されているタスクの1つを解決しているときに（Ray Seyfarthによる）、次の問題に遭遇しました。

.bss セクションのバッファにいくつかの文字を配置すると、gdb でデバッグ中に空の文字列が表示されます。.data セクションのバッファに文字を配置すると、gdb で期待どおりに表示されます。

segment .bss
result  resb    75
buf resw    100
usage   resq    1

    segment .data
str_test    db 0, 0, 0, 0

    segment .text
    global main
main:
    mov rbx, 'A'
    mov [buf], rbx          ; LINE - 1 STILL GET EMPTY STRING AFTER THAT INSTRUCTION
    mov [str_test], rbx     ; LINE - 2 PLACES CHARACTER NICELY. 
    ret

gdbで私は得る：

  • LINE 1: の後x/s &buf、結果 -0x7ffff7dd2740 <buf>: ""

  • 行 2 の後: x/s &str_test、結果 -0x601030: "A"

が正しいアドレスに評価されていないように見える&bufため、まだすべてゼロが表示されます。0x7ffff7dd2740 は、その によると、デバッグ中のプロセスの BSS にない/proc/PID/mapsため、意味がありません。 が間違ったアドレスに評価されるのに、正しいアドレスに評価されるのはなぜ&buf&str_testですか? どちらも「グローバル」シンボルではありませんが、デバッグ情報を使用してビルドしました。

x86-64 Ubuntu 15.10 上の GNU gdb (Ubuntu 7.10-1ubuntu2) 7.10 でテスト済み。

で構築しています

yasm -felf64 -Worphan-labels -gdwarf2 buf-test.asm
gcc -g buf-test.o -o buf-test

nm実行可能ファイルでは、正しいシンボル アドレスが表示されます。

$ nm -n  buf-test     # numeric sort, heavily edited to omit symbols from glibc
...
0000000000601028 D __data_start
0000000000601038 d str_test
... 
000000000060103c B __bss_start
0000000000601040 b result
000000000060108b b buf
0000000000601153 b usage

（編集者注：奇妙さはOPのasmではなくgdbの動作にあるため、多くの質問を書き直しました！）。

4

1 に答える 1

3

glibc には、 という名前のシンボルも含まbufれています。

(gdb) info variables ^buf$
All variables matching regular expression "^buf$":

File strerror.c:
static char *buf;

Non-debugging symbols:
0x000000000060108b  buf            <-- this is our buf
0x00007ffff7dd6400  buf            <-- this is glibc's buf

gdb はたまたま実行可能ファイルのシンボルよりも glibc のシンボルを選択します。ptype bufこれが を示す理由char *です。

バッファーに別の名前を使用すると、問題が回避さglobal bufれ、グローバル シンボルにすることもできます。また、libc をリンクしないスタンドアロン プログラムを作成した場合 (つまり_start、を実行する代わりに exit システム コールを定義して作成する場合ret)も問題はありません。

0x00007ffff7dd6400(私のシステムのアドレスbuf; あなたのものとは異なります) は、実際にはスタックアドレス ではないことに注意してください。視覚的にはスタック アドレスのように見えますが、そうではありません。. のf後の桁7数が異なります。コメントの混乱と質問の以前の編集について申し訳ありません。

共有ライブラリは、仮想アドレス空間の下位 47 ビットの最上部近く、スタックがマップされている場所の近くにもロードされます。それらは位置に依存しませんが、ライブラリの BSS スペースはそのコードに対して適切な場所になければなりません。/proc/PID/mapsもう一度注意深く確認すると、gdb&bufは実際には、libc-2.21.so..

7ffff7a0f000-7ffff7bcf000 r-xp 00000000 09:7f 17031175       /lib/x86_64-linux-gnu/libc-2.21.so
7ffff7bcf000-7ffff7dcf000 ---p 001c0000 09:7f 17031175       /lib/x86_64-linux-gnu/libc-2.21.so
7ffff7dcf000-7ffff7dd3000 r-xp 001c0000 09:7f 17031175       /lib/x86_64-linux-gnu/libc-2.21.so
7ffff7dd3000-7ffff7dd5000 rwxp 001c4000 09:7f 17031175       /lib/x86_64-linux-gnu/libc-2.21.so
7ffff7dd5000-7ffff7dd9000 rwxp 00000000 00:00 0        <--- &buf is in this mapping
...
7ffffffdd000-7ffffffff000 rwxp 00000000 00:00 0              [stack]     <---- more FFs before the first non-FF than in &buf.

rel32 エンコーディングの通常の命令はライブラリ関数に到達できませんが、GNU/Linux 共有ライブラリはシンボルの挿入をcallサポートする必要があるため、その必要はありません。 GOT からのポインター) が最終的な宛先に移動します。calljmp

于 2016-08-30T10:01:19.570 に答える