web-dev-qa-db-ja.com

linux-vdso.so.1の共有ライブラリシンボルを読み込めませんでした。デバッグ中

VDSO.soをロードしないことは、gdbおよびglibc> 2.2の使用中に発生する有名なバグの1つです。それはgdb7.5.1で修復される予定でしたが、そうではありませんでした。さて、ここで回避策を見つけました ここ 、しかし私はそれを理解していなかったので、それを適用する方法。

OS：Arch Linux
IDE：QTクリエーター3.0.82
コンパイラ：GCC 4.8.2
注：上記のリンクを含むルールに違反しているかどうかはわかりません

linuxgdbglibc
14
Shady Atef

VDSO.soをロードしないことは、gdbおよびglibc> 2.2の使用中に発生する有名なバグの1つです。

いいえ、そうではありません。ここでの問題は、単に役に立たない警告であり、無視しても問題ありません。

ここで回避策を見つけましたが、理解できなかったので、どのように適用するか。

「回避策」が見つかりませんでした。警告を無効にするGDBへのパッチが見つかりました。

これを適用するには、patchコマンドを使用してから、独自のGDBをビルドします。しかし、そもそも警告を無視する方がはるかに簡単です。

17
Employed Russian

（私のように）gdbにシンボルの欠落についてシャットダウンさせたいだけの人は、これを~/.gdbinitに追加してみてください（ただし、以下の警告を参照してください）。

set logging redirect on
set logging file /dev/null
python
def on_new_objfile(e):
    gdb.execute("set logging off")
    #print "new objfile:",e.new_objfile.filename
    if e.new_objfile.filename[:19] == "system-supplied DSO":
        gdb.execute("set logging on") # hide inevitable error message
gdb.events.new_objfile.connect(on_new_objfile)
end

警告：

  • set loggingインターフェースを独占します。ロギングを使用する場合は、以前のロギング設定を保存するようにログを変更する必要があります。
  • ハードコード"system-supplied DSO";新しいカーネルまたはgdbバージョンでは脆弱である可能性があります。
  • 出力を再度有効にするために、少なくとも1つのobjfileがロードされることを前提としていますafter vdso; vdsoが最後にロードされたobjfileである場合、プログラムの開始時に出力が無効のままになるリスクがあるため、gdbの内部知識が豊富な人が実際のafter-symbol-load-has-failedフックを指摘できるかどうか非常に興味があります。
6
David X