search for: mspdb140

On Tue, Jul 26, 2016 at 8:02 AM, Reid Kleckner <rnk at google.com> wrote: > We've been pursuing the direction of writing PDBs from scratch in > llvm/lib/DebugInfo/PDB/Raw and related directories. It might be interesting > to have code that talks to MSPDB140.dll in LLVM, but we really want LLD to > be able to produce its output on any platform. > I completely agree about independence from arbitrary platform-specific binaries. (After all, escaping LINK.EXE just to rely on MSPDB140.dll isn't that huge of a win by itself.) I forgot to mentio...

...9;m happy to report success as of this afternoon. More details about the effort and its status can be found at [0]. The high-level overview of my strategy is to crack the CodeView blob from LLVM (.data$S COFF section) and reassemble it, plus some augmentation, then feed that to the API exposed by MSPDB140.dll (Visual Studio 2015's version). This works and I can debug programs in both VS and WinDbg assuming the front-end supplies sane metadata to the LLVM layer. My question to the list - is this work valuable for anyone else? Would there be general interest in documentation or even example code...

On Wed, Jul 27, 2016 at 12:06 AM, Johan Wehrli <johan.wehrli at strong.codes> wrote: > > Most of the time, it is a path problem: > https://support.microsoft.com/en-us/kb/3035999 > > If you open the file cmake/config-ix.cmake you will find the place where > cmake check if the DIA_SDK is present (there is also a note saying that > sometime this is a Windows bug). > >

Hi Mike, > I'll check into that again. I ran across llvm-pdbdump earlier but couldn't get it to build on a vanilla 3.8 install (CMake is convinced I don't have the DIA SDK and I haven't found a way to change its mind). I have experienced something similar with the DIA SDK. Most of the time, it is a path problem: https://support.microsoft.com/en-us/kb/3035999