PDB mode pretty instable

[Sebastian Werhausen]

The Clang mode wasn't viable to my usecases, so all of this only refers to the PDB mode.

I'm still having trouble getting it to work reliably. For example right now, this program leads to the usual "no structure found at the given position" dialog:

#include <string>
#include <vector>

struct str
{
   char a;
   int b;
   char c;
};

int main()
{
   str t{};
   return 0;
}

If I remove the vector include or change the struct layout, things work. For example if I change the struct to

struct str{
   int a;
}

it works. If I then change back to the original struct, I get this:

So he somehow reads back the old code. All of this is pretty unreliable and I can often get a code to work which did not prior and the other way round. In particular I found a rebuild fix the "wrong struct" errors.

So there are really two main problems:

1. Displaying old layouts (fixable by rebuild)
2. Things not working at all (Some fixable by rebuild, but some never)

I'm using VS2022, debug mode and have things compiled and cursor on the first line, just as instructed.

The overall pattern what works and what not isn't clear. The unfixable errors certainly happen more often in complex types from "real" projects. They might have things like members of library types, precompiled headers, functions, forced includes etc. Not sure if any of that makes things harder on the parsing side. Those complexities make it harder to isolate the problem unfortunately.

[Ramon Viladomat]

There are several differences between the clang extractor and the pdb extractor:

• Clang extractor : grabs the source files as they are in disk and parses them grabbing the layout data from the Clang AST.
• PDB extractor : grabs the pdb file ( which needs to be up to date by compiling the code prior to consulting ) and using the Microsoft DIA SDK tries to extract the layout data from there. This means that local modifications without building won't be represented in the current pdb file. On top of that the compiler might omit some types in the pdb if they are never used or other reasons. Also the DIA SDK sometimes is not super reliable on the structures that lets you inspect. I am investigating other approaches to have more reliable pdb data extraction. ( for example DIA SDK is quite bad dealing with virtual inheritance or just not having the requested type information at all )

Sadly I am quite busy at the moment, I will go back to it once I have some spare time.

[n00bmind]

Just wanted to point you to a tool I've seen regarded highly in some Twitter circles, in case you haven't heard of it.. might help easy out the dread of dealing with the DIA SDK..
https://github.com/MolecularMatters/raw_pdb

Me personally I haven't yet managed to get PDB mode to work, even after pointing it to the full path of the pdb for the currently running .exe .. is there an increased verbosity option we can toggle anywhere to help diagnose the exact issue?

[n00bmind]

Oh, forgot to mention I never have intellisense enabled (since the "no structure found" error dialog mentions it). Is that a pre-requisite?

[Ramon Viladomat]

Intellisense is not a prerequisite, but sadly the DIA SDK does not provide ( or I could not find a way to get ) the location of where a symbols starts and ends. It only provides the starting line. If the Visual studio code model is enabled, I am leveraging that so I can get the starting line of the scope we are currently at and then perform the query to the PDB via the DIA SDK using the starting line location. This means that you can still perform queries if done at the struct/class starting line.

That being said, I wanted to also hook raw_pdb as it seems to produce more solid results, but sadly it does not provide source file location. I could do a search based on symbol name, but then I have symbol name aliasing as it might be tricky to extract the wanted symbol's full name. ( A::MyStruct vs B::MyStruct vs C::D::MyStruct ... )

This means I might need to add some way to report back all matches and then allow the user to select the one they wanted in case of ambiguity, which I wanted to add for templates and other cases at some point.

I will get to add these things eventually but I don't have the bandwidth at the moment to work on it.