Symbol file acceleration structures

x13pixels  —  1 month ago [Edited 0 minutes later]
The last couple of days I've been working on RemedyBG's call-stack display and realized that the acceleration structures that are baked into the PDB may be useful to Microsoft for linking but they sure suck for a debugger.

For instance, there is a hash-table (chained for resolving collisions) that you can read from the PDB (after "decompressing" and fixing up ptrs) for both public and global symbols. However, the symbols they resolve to are either i) symbols with only a name and location (section/offset) -- not detailed enough (e.g., we want the function's type, #arguments, info on FPO optimizations, etc.) -- or ii) a reference into the sections symbol table which actually does have this information. Though these more detailed symbols, the ones you actually want, don't have any meaningful baked data structures for accelerating look-ups.

I also noticed that VS2017 adds duplicate records (e.g., WinMain multiply added) to the symbol stream (sometimes with incorrect segment offsets) every time you build (with no change to the source file). Maybe the linker is appending to the stream rather than having to clean up for "speed"? In any case, I never trusted dbghelp.dll, DIA, or any of MS's symbol reading "helpers" (buggy as hell) and now I'm eschewing the baked in acceleration structures and writing my own rather than dancing through the PDB's.

BTW, for additional testing I've been walking through the Handmade Hero videos from the beginning and making sure that RemedyBG has (at least) feature parity with the set of Visual Studio that is being used on stream. I was thinking about putting together videos mashing up the excerpt's of HH that are using Visual Studio with an overlay of RemedyBG/Vim doing the same thing. Any suggestions on software for doing something like this?

Log in to comment