我正在尝试调试来自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源。

10-07 19:12
查看更多