我正在尝试调试来自Crypto ++库的一些代码,但是在 session 期间我得到了无关紧要的信息。
感兴趣的功能是DEREncodePrivateKey
。它是DL_PrivateKey_EC<T>
的成员函数(Crypto ++已大量模板化)。
228 pk.DEREncodePrivateKey(encoder);
(gdb) s
non-virtual thunk to CryptoPP::DL_PrivateKey_EC<CryptoPP::ECP>::DEREncodePrivateKey(CryptoPP::BufferedTransformation&) const
(this=0x7fff5fbfeca0, bt=@0x7fff5fbfe540) at dll.cpp:690
Line number 690 out of range; dll.cpp has 146 lines.
dll.cpp可以在trunk / c5 / dll.cpp上找到,它只报告了146行广告gdb。
该对象刚好在相关行的前面
dynamic_cast
:const PKCS8PrivateKey& pk = dynamic_cast<const PKCS8PrivateKey&>(key);
我使用
-O0 -g3
从源代码构建了库,因此我认为我最小化了一些/大多数典型问题。我尝试使用不同的编译器(g++和clang++)来构建库和测试程序,并且尝试使用不同的调试器(gdb和lldb)对其进行调试。但是我仍然得到了一些无关紧要的信息,因此图书馆无法在这个领域步入正轨。其他区域都可以(在发行前可以看到)。
我也确定我正在使用我的库版本。使用库的完整路径将其链接为静态库,并且
info shared
确认Apple没有潜入动态库中。我需要迈步
DL_PrivateKey_EC<CryptoPP::ECP>::DEREncodePrivateKey
看看发生了什么。我认为正在调用的函数在eccrypto中,但我想在调试器中查看它。任何想法如何进行?
最佳答案
听起来调试信息中的行表不正确。在Mac OS X上,您可以使用dwarfdump --debug-line appname.dSYM
转储行表,或者如果您正在查看特定的目标文件dwarfdump --debug-line dll.o
。在lldb中,您还可以执行target modules dump line-table dll.cpp
。我的猜测是,头文件中的某些函数已从690行内联到您的dll.cpp
中,但是该线表可能会错误地忘记从dll.cpp
切换到您的头文件。
从g++和clang++看来,您似乎不可能看到相同的问题。我怀疑您的项目至少有一部分没有重建。
您可以在此处继续进行调试-唯一的问题是,在逐步执行方法时,调试器不会向您显示源。但是您可以继续前进,我希望您很快就会再次回到dll.cpp源。