Open randomascii opened 7 years ago
Hm ... you would need the exact same Visual Studio version to use the pdb file, wouldn't you?
No, that is not true. The PDB format is highly forward/backward compatible. There are some cases where you need a "new enough" version of Visual Studio or windbg but you never need exactly the same version and I have practically never found PDB/tool versioning to be a problem.
BTW, another prime consumer of the PDB data would be the Windows Performance Toolkit (WPA, the ETW trace viewer) and it handles all known versions of the PDB format.
I see, thanks.
When debugging ninja, wouldn't you also need the source anyway?
Also some optimizations make it harder to use a Release build for debugging/profiling.
Having the source is definitely advantageous. However even just having function names is a huge step up when looking at a crash dump. Many crashes can be diagnosed with just that information. And, if source is important then it is possible to track down the source (source indexing makes this automatic, so if that is embedded in the PDB then source will show up automatically).
For profiling it is very common to only care about function names, so source is often irrelevant.
As an example look at Microsoft's publishing of symbols. They routinely publish function-name-only PDBs for all of their software on symbol servers and this has been incredibly valuable. There is no reason to believe that the git symbols would be any less valuable.
@randomascii Now that Ninja uses the new Github Actions continuous integration system to manage releases, you should be able to make a PR that addresses this need directly.
In case of crashes or a need to profile ninja it would be nice to have a PDB. Yes, I can rebuild it from source but it would be easy enough (I think) to add the .pdb to the release .zip file.