views:

132

answers:

3

Hi, I have a project that is C++ WIN32 project. I found a problem that some symbol can be recognized by the windbg but some don't. I don't know why. The characteristics are:

1) both are C++ method

2) both function are in one .cpp file

3) the two functions are very close in the source file and neither of them are enclosed by a #ifdef

4) I have used dbh.exe to check the symbol, the symbol missing in the windbg is also not in the pdb file.

I am guessing if the symbol missing may due to the inheritance of the class? Please suggest, thanks! Bin

A: 

Is the function ever called?

It might help to give some more details on why you think it is "due to the inheritance of the class"

gatorfax
A: 

It sounds like the source code may be incompatible with the PDB files.

Maybe the function was added after the PDB file was generated?

You can validate this by:

  1. Add a break point to a line of code that you know will be executed.
  2. Step through the code and ensure that the debugger doesn't stop on any blank lines of code (this would imply a mismatch between code and PDB file).

The first thing I would suggest is to rebuild the source code to see if that fixes the problem.

If this doesn't work, please provide more information to allow us to help you diagnose this further.

LeopardSkinPillBoxHat
+3  A: 

If you don't use a function, as long as it is not a virtual function, it may be deadstripped by the linker. Unused global data objects may be deadstripped as well.

Adisak
Oh, yes, it's exactly the reason. I add an explicit call to that function, then it appears on the pdb file. Thanks.To be clear, originally the function is referenced by function pointer, thru the CreateThread(). I think this implicit call makes the compiler think it's not used by the code so it stripped the symbol.If there is any method to forcible ask compiler to add the indirectly referenced function to symbol file?Thanks.
Bin Chen
If you take the address of the function the linker shouldn't remove the function (it can't really) and it should leave symbolic information for the function in the debug information. Can you add a bit of code (the function signature and the CreateThread call)?
Michael Burr
Actually the function is called with the function that is passed as address to CreateThread():CreateThread(... func_a);func_a(){func_b();}func_a is listed in the pdb file but func_b isn't.
Bin Chen
Correction:with -> within
Bin Chen
Actually, even if an unused function is virtual the linker may remove it. The current linkers don't do this yet, because it's slightly harder to prove a virtual function is unused. However, an opportunistic signature-based check can find some unused virtual functions, so it's a realistic linker improvement.
MSalters
@MSalters: I know of no compilers that remove virtual functions. Also, in Windows, it is possible to share C++ objects between EXE's and DLL's so deadstripping virtual functions would likely cause many programs on that platform to crash. It's possible, the same may hold true as well for Linux C++ dynamic libraries. You can only safely remove virtual functions for purely "static" programs which can guarantee no virtual function interaction between external system or dynamically linked code and the user code - since that guarantee is all but unenforceable, vf-stripping is impractical.
Adisak