For some reason, when building in Visual Studio it decides to put out two PDBs: a partial PDB file along with another PDB file (e.g., vc141.pdb). The PDB baked into the EXE headers points to the partial PDB and this is the one that RemedyBG loads. Since the PDB does not contain full type information RemedyBG fails to behave as expected.
It looks like WinDBG has the same problem when loading up an executable with a partial PDB. It shows (after enabling verbose symbol information with "!sym noisy"):
DBGHELP: some.pdb is a partial PDB and can't enumerate symbol information.
I haven't yet figured out the compiler / linker switch to make Visual Studio build a single, full PDB nor the secret sauce that VS is using to find this secondary PDB. Does anyone here know how? Note that building Handmade Hero from the batch file works fine and does not exhibit this problem.
In any case, RemedyBG probably won't be supporting partial PDBs in the near term. I'd like to at least have a better answer and/or checks to handle this case.
Any help would be greatly appreciated. Thanks!
--
George
It looks like WinDBG has the same problem when loading up an executable with a partial PDB. It shows (after enabling verbose symbol information with "!sym noisy"):
DBGHELP: some.pdb is a partial PDB and can't enumerate symbol information.
I haven't yet figured out the compiler / linker switch to make Visual Studio build a single, full PDB nor the secret sauce that VS is using to find this secondary PDB. Does anyone here know how? Note that building Handmade Hero from the batch file works fine and does not exhibit this problem.
In any case, RemedyBG probably won't be supporting partial PDBs in the near term. I'd like to at least have a better answer and/or checks to handle this case.
Any help would be greatly appreciated. Thanks!
--
George
Edited by x13pixels
on
Reason: Initial post
/Z7
It makes compiler to put debug info inside .obj files. Which linker uses to produce final .pdb file.
Default /Zi debug makes .pdb generation in one output file, not .obj files. This happens by creating separate process mspdbsrv.exe which cl.exe communicates over some IPC to give it debug info to save to avoid complex multi-process synchronization when writing to one .pdb file. Not sure how/what it does to create final .pdb file & associate with .exe file.
It makes compiler to put debug info inside .obj files. Which linker uses to produce final .pdb file.
Default /Zi debug makes .pdb generation in one output file, not .obj files. This happens by creating separate process mspdbsrv.exe which cl.exe communicates over some IPC to give it debug info to save to avoid complex multi-process synchronization when writing to one .pdb file. Not sure how/what it does to create final .pdb file & associate with .exe file.
Edited by Mārtiņš Možeiko
on