GDBはxx.soのグローバルデータを実行ファイルなしで解析できますか？

Question

私はLinuxシステム上で実行されている共有ライブラリ（hlapi.so）を持っています。このhlapi.soには多くのモジュールがあります（私は.cファイルを意味します）。そのうちの一つは、このような二つのグローバル件のデータを定義するhlapi.cとして命名されています。もちろん

static int hlapiInitialized = FALSE; 
static struct hlapi_data app_sp; 

このhlapi.cモジュールの他の多くのコードがあります。 hlapi.soは、hlapi.soに基づいて独自のアプリケーション（appbasehlapiという名前）を作成する顧客にリリースされます。

は今、私は、そのバックトレース顧客によって解析されたコアは、私たちのコードであることを示しているコアダンプを得ました。しかし、顧客はコアダンプファイルのみを提供することができます。 appbasehlapi実行ファイルは私たちと共有されません。私の手では、コアダンプファイル+ hlapi.soしか持っていません。

このコアをデバッグするために、私はコマンドによって

gdb --core=mycoredumpfile 

をコアダンプファイルをロードし、GDBで、私はそうhlapi.so含まれているフォルダを指定する

set solib-search-path . 

を使用gdbはhlapi.soからシンボルをロードできます。そして、私は以下を使用します：

print hlapiInitialized 
print app_sp 

私たちのモジュールでグローバルデータを解析します。しかし、出力値は非常に異常です。

実行可能ファイルなしでhlapi.soで定義されたグローバルデータをgdb経由で解析できるのですか？もし私がgdb経由で得た出力が信じられないのであれば？ コメントありがとうございます。

ところで、hlapi.soは、gccのオプション "-g -fPIC" で構築されています。

Answer 1

私はしばらくの間、質問を調査し、私の意見では、私は、GDBが実行せずにグローバル変数を解析することができると信じて。試験において

、以下のコードはhlapi.cppである：

static int hlapiInitialized = 0; 

void hlapiInit() 
{ 
    if (hlapiInitialized == 0) 
    { 
     // do something else 
    } 

    hlapiInitialized = 1; 
} 

objdumpは、それのためにアセンブリコードを示している。

00000000000009a2 <_Z9hlapiInitv>: 
9a2: 55      push %rbp 
9a3: 48 89 e5    mov %rsp,%rbp 
9a6: c7 05 98 06 20 00 01 movl $0x1,0x200698(%rip) # 201048 <_ZL16hlapiInitialized> 
9ad: 00 00 00 
9b0: 90      nop 
9b1: 5d      pop %rbp 
9b2: c3      retq 

アプリケーションを実行している間、私は、コアを生成それに対してダンプする。 GDBでは、solib-検索パスを指定する前に、私が手：検索パスが指定されると

(gdb) disas hlapiInit 
No symbol table is loaded. Use the "file" command. 

、出力は次のようになります。

(gdb) disas hlapiInit 
Dump of assembler code for function hlapiInit(): 
    0x00007ffff7bd59a2 <+0>: push %rbp 
    0x00007ffff7bd59a3 <+1>: mov %rsp,%rbp 
    0x00007ffff7bd59a6 <+4>: movl $0x1,0x200698(%rip)  # 0x7ffff7dd6048 <_ZL16hlapiInitialized> 
    0x00007ffff7bd59b0 <+14>: nop 
    0x00007ffff7bd59b1 <+15>: pop %rbp 
    0x00007ffff7bd59b2 <+16>: retq 
End of assembler dump. 

hlapi.soからとの出力を比較した後共有ライブラリがプロセスにロードされると、グローバル変数のアドレスが再割り当てされ、グローバル変数のアドレスがクリアされることがわかりました。したがって、共有ライブラリのシンボル情報を取得すると、gdbは変数をマップできます。