[PDB] Base class are not recognized for the derived class, local variables names are not recognized

[SmileyAG]

Describe the bug This non-detection of the base class for derived affects all functionality: graph of type, disassembler, decompiler, structure editor and etc

I tried importing other x86 projects that were compiled on different versions of MSVC and the result was the same everywhere. IDA does not have such issues in comparison, so I am sure that the issue clearly ties to the PDB parser from Ghidra

Here is CBasePlayer::Jump function from source code of the project on the basis of which another project was made that is shown in the screenshots and the files of which are attached to this issue: https://github.com/HLSources/Paranoia/blob/c2d8018e3fa9de209ba76c0bbe8491bc09d8d797/code_src/dlls/player.cpp#L1892

In the first screenshot you can clearly see the absolute similarity of the names of local variables and members of class (including members from inherited classes) in the result from IDA decompiler shown in the screenshot in comparison with the provided source code, so this data indeed matches Meanwhile, Ghidra cannot recognize local variable names or members of base classes in a derived class (CBasePlayer) from a PDB file

In the second screenshot you can see that Ghidra creates empty fields as alignment from the size of the base class IDA also does alignment, but it recognizes what exactly the base class (CBaseMonster), which gives you an explanation of why and from whom the alignment was made

Here's the CBasePlayer class hierarchy for investigate from the provided binaries in case if needed:

CBaseEntity -> CBaseDelay -> CBaseAnimating -> CBaseToggle -> CBaseMonster -> CBasePlayer

To Reproduce Steps to reproduce the behavior:

• Import any binary and its .pdb into Ghidra for analysis, simply enough. Default analysis options were used.

Screenshots

Attachments cry-of-fear-14-server-binary-with-pdb.zip application.log

Environment (please complete the following information):

• OS: [Windows 10, 64 bit]
• Java Version: [jdk-17.0.2]
• Ghidra Version: [11.0.3]
• Ghidra Origin: [official GitHub distro]

[ghizard]

There are two issues here. First is the PDB base class issue, which was worked on but not turned on due to reliable ways of portraying and saving the information... this is being looked at again at this time, and there might be ways to supply better information that the long-term goal.

The second issue is concerning setting variable names for the Decompiler. This is a tougher issue to deal with and my understanding is that due to the many transformations that occur within the Decompiler, it might be much tougher to solve. Probably needs both Decompiler work as well as a "retry" of using Decompiler capabilities to set the names.

We have internal tickets for both of these issues. Feel free to create a separate ticket for this second issue so we can track it better.

If/when we have something more to offer you, we will reply again. For the base class issue, you might try to set the PdbDeveloperMode launch option to true and then in the PDB Universal Analyzer, change the "Composite Layout Choice" from "Legacy" to "Complex with Simple Fallback." Some of the inherent issue have to do with information of child classes overlaying information of base classes.