CODEWITHSUNDEEP
c++debugginggdblldb
jww
jww

Reputation: 102205

Debugger can't match source or step code in library

I'm trying to debug some code coming from the Crypto++ library, but I'm getting non-sensical information during the session.

The function of interest is DEREncodePrivateKey. Its a member function on DL_PrivateKey_EC<T> (Crypto++ is heavily templated).

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 can be found at trunk / c5 / dll.cpp, and it only has 146 lines ad gdb reported.

The object was dynamic_cast just before the line in question:

const PKCS8PrivateKey& pk = dynamic_cast<const PKCS8PrivateKey&>(key);

I built the library from sources with -O0 -g3, so I think I minimized some/ most of the typical problems.

I've tried building the library and my test programs with different compilers (g++ and clang++), and I've tried debugging it with different debuggers (gdb and lldb). But I still get the non-sensical information and the library cannot be stepped in this area. Other areas are OK (as can be seen before the issue).

I'm also certain that I'm using my version of the library. Its being linked as a static lib using the full path to the library, and info shared confirms Apple is not sneaking in a dynamic library.

I need to step DL_PrivateKey_EC<CryptoPP::ECP>::DEREncodePrivateKey to see what's going on. I think the function that's being called is in eccrypto, but I'd like to see it under the debugger.

Any ideas how to proceed?

Upvotes: 1

Views: 644

Answers (1)

Jason Molenda
Jason Molenda

Reputation: 15375

It sounds like the line table in the debug info is incorrect. On Mac OS X you can dump the line table with dwarfdump --debug-line appname.dSYM or if you are looking at a specific object file, dwarfdump --debug-line dll.o. From within lldb you can also do target modules dump line-table dll.cpp. My guess is that some function from a header file was inlined into your dll.cpp -- from line 690 -- but the linetable may incorrectly forget to switch from dll.cpp to your header file.

It seems unlikely that you would see the same problem from both g++ and from clang++. I suspect at least part of your project was not rebuilt.

fwiw you can continue debugging here -- the only problem is that the debugger won't be showing you the source as you step through your method. But you can continue to step and I expect you'll be back in your dll.cpp sources again in no time.

Upvotes: 1

Related Questions