[Turn] PDB related knowledge of static library

This article is transferred from: http://blog.sina.com.cn/s/blog_41299a9701018bs8.html

I encountered a Crash today. Crash was in a third-party library. I took a look at it out of curiosity. It is found that the code is not there. We can only see the header file, only the Crash Call Stack of others, and even the Dump file, so we can only simulate and reproduce it manually.

  It is found that the target module of Crash is A.dll, which is our own code, but the third-party library of Crash is statically linked into it. That is to say, the actual code of Crash is written by a third-party library, there is no source code, but VS can even display the line number! The disassembly can actually show the file name, which is strange. Where does the information come from? VS cannot be generated by itself, so I studied it.

  There are two possibilities here

  1. It uses the PDB of the library file provided by a third party, and I found it, and it really does. But when VS is debugging, this file can be deleted, indicating that it is not being used.

  2. It copies the content of this PDB to A.pdb. This is actually the case, and I found A.pdb. The question is again, who is the source of the copy? We know that lib includes code, so does it also include PDB information? Is the PDB information copied from Lib when it is Link? I checked Lib and found that there were source file information and PDB information, but I was still not sure.

  Prepare to do the following experiments to verify that the PDB information is in Lib itself, or to find the library's PDB through it, and then copy it from the library's PDB to A.pdb. Rename the target PDB and recompile the A project. If you still bring the PDB information of the third-party library, it is in Lib. If not, it is in the PDB.

 

  After verification, I think I have found the answer, find the PDB through the lib, and then copy it.

d.lib(1.obj) : warning LNK4099: PDB 'd.pdb' was not found with 'd.lib(1.obj)' or at 'C:\d.pdb'; linking object as if no debug info

  The other thing is to verify that if you see which class RCX represents without the source code, you need to add the module offset based on the type information. Then according to the virtual table offset, determine which virtual function is, and then cooperate with the header file to find the function name, or directly F11, the CALL Stack displayed by the PDB information will also tell us this, and some things are mutually confirmed.

Guess you like

Origin blog.csdn.net/gouguofei/article/details/103194870