GoにリンクされたCGOコードのデバッグシンボルを取得する方法はありますか？

Question

GoバイナリにリンクしているCgoコードがあります。私はCgoを実行して、コードとラッパーを構築しています。最近のいくつかの変更の後で、私はリンクしている私のC + +でダブルフリーを取得し始めた。私はlldbの下で私のバイナリを実行しようとしたが、mallocパニックをトラップしますが、

バニラCまたはC++では、変数名とソースを含む豊富なデバッグシンボルを取得するために-g3を使用しました。これにより、lldbの使用はずっと効率的になります。しかし、私はいくつかの問題は、これらのシンボルを私の行くバイナリに表示されている。バックトレースで私の機能はmain'fooと表示されています。ここでfooは私の関数の名前です。しかし、他にデバッグ情報はありません。アセンブリとメモリポインタ/レジスタのトレースがあります。

私はでgo buildを呼び出そうとしましたが、バイナリにはまだシンボルがありません。また、を私の.goファイルのCFLAGS/CXXFLAGSに追加しようとしましたが、他のフラグ（import "C"の前）を設定しましたが、これはどちらかと思われません。このデバッグ情報を私のバイナリに追加する他の方法は考えられません - これを可能にするGo固有のフラグやビルドシーケンスがありますか？

Answer 1

私はどのように行くのプロセスがわからない& C++のリンクが動作します。しかし、OS Xでデバッグ情報をどのように処理するかについての簡単な説明は、デバッグ情報がどこに失われているかを理解するのに役立ちます。

OS Xでは、ほとんどのシステムと同様に、個々のソースファイルのデバッグ情報はコンパイルされた.oファイルに書き込まれます。 ...

lldb -o "image dump sections" Target.o --batch | grep DWARF 
    0x00000300 container  [0x0000000000061538-0x0000000000782c77) rwx 0x00061cb8 0x0072173f 0x00000000 Target.o.__DWARF 
    0x00000009 dwarf-str  [0x0000000000061538-0x00000000004eeabc) rwx 0x00061cb8 0x0048d584 0x02000000 Target.o.__DWARF.__debug_str 
    0x0000000a dwarf-loc  [0x00000000004eeabc-0x00000000004ef493) rwx 0x004ef23c 0x000009d7 0x02000000 Target.o.__DWARF.__debug_loc 
    0x0000000b dwarf-abbrev  [0x00000000004ef493-0x00000000004f09a7) rwx 0x004efc13 0x00001514 0x02000000 Target.o.__DWARF.__debug_abbrev 
    0x0000000c dwarf-info  [0x00000000004f09a7-0x00000000006ea7f1) rwx 0x004f1127 0x001f9e4a 0x02000000 Target.o.__DWARF.__debug_info 
    0x0000000d dwarf-ranges  [0x00000000006ea7f1-0x00000000006ec481) rwx 0x006eaf71 0x00001c90 0x02000000 Target.o.__DWARF.__debug_ranges 
    0x0000000e dwarf-macinfo [0x00000000006ec481-0x00000000006ec482) rwx 0x006ecc01 0x00000001 0x02000000 Target.o.__DWARF.__debug_macinfo 
    0x0000000f apple-names  [0x00000000006ec482-0x000000000071134e) rwx 0x006ecc02 0x00024ecc 0x02000000 Target.o.__DWARF.__apple_names 
    0x00000010 apple-objc  [0x000000000071134e-0x0000000000711372) rwx 0x00711ace 0x00000024 0x02000000 Target.o.__DWARF.__apple_objc 
    0x00000011 apple-namespaces [0x0000000000711372-0x00000000007116d6) rwx 0x00711af2 0x00000364 0x02000000 Target.o.__DWARF.__apple_namespac 
    0x00000012 apple-types  [0x00000000007116d6-0x0000000000748797) rwx 0x00711e56 0x000370c1 0x02000000 Target.o.__DWARF.__apple_types 
    0x00000015 dwarf-line  [0x000000000075d348-0x0000000000782c77) rwx 0x0075dac8 0x0002592f 0x02000000 Target.o.__DWARF.__debug_line 

あなたはその後、コンパイラはデバッグ情報を放出されていない、ここには何も表示されない場合

を：あなたの.oファイルは、さまざまな方法でデバッグ情報を持って、ここで1だことを確認することができます

次のステップは、デバッグ情報をリンクステージの出力に入れる代わりに、デバッグ情報を.oファイルに残し、出力イメージに「デバッグマップ」を挿入する代わりに、Darwin固有のステップです。これは、デバッガが.oファイルに戻る方法を示しています。

$ nm -ap <YourBinary> | grep OSO 

ここにすべての.oファイルのリストが表示されます。ビルドプロセスのある時点で、バイナリが取り除かれている場合（少なくともstrip -Sを使用）、それがいつ起きているのか調べなければなりません。また、.oファイルが、上記のコマンドで表示されているエントリがどこにあるかを確認します。ビルドプロセスのいくつかの部分がそれらを動かしているかもしれないし、デバッガはもうそれらを見つけることができません。