<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 28, 2016 at 8:21 PM, Michael Lewis <span dir="ltr"><<a href="mailto:don.apoch@gmail.com" target="_blank">don.apoch@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I will certainly be willing to speak up if I find anything I know that isn't represented here already.</div></div></div></div></blockquote><div><br></div><div><br></div><div>After continuing to poke around in llvm-pdbdump for a weekend, I feel like there's more represented in it than I know personally of the file format; but in any case, I'm (slowly) writing up more notes at [0] to describe how I'm using the information gleaned to build a usable PDB.</div><div><br></div><div><br></div><div>I'm getting sane callstacks and source-level debugging (line numbers) using the MSPDB140.dll approach, and I have basic high-level raw data emitted as well. I'll start working on raw-emitting symbols and line numbers over the next week or so. Once I have feature parity between my raw emitter and the MSPDB140.dll method, I'll tackle type data generation and see if I can get locals/function params to be debuggable as well.</div><div><br></div><div>This all works in VS2015 and WinDbg, btw. Binaries are 64-bit. Stack unwind data is generated fine by other means in LLVM, this just enables a debugger or a library like DbgHelp.dll to attach function names to the stack frames. Presumably with accurate type data I'll be able to see function params. A little bit of investigation should net locals as well, although stack/register mappings back up to code identifiers might be tricky, I don't know yet.</div><div><br></div><div><br></div><div>To slightly change the tack of my original question - it seems like this might be more useful to the community as a front-end developer's HOWTO rather than a back-end file-construction kit. Since LLVM trunk already has considerable support for reading and writing PDBs, maybe the best approach is to start collecting wisdom on how to actually populate them?</div><div><br></div><div><br></div><div><br></div><div> - Mike</div><div><br></div><div><br></div><div><br></div><div><br></div><div>[0] - <a href="https://github.com/apoch/epoch-language/wiki/Knowledge-Dump---Debugging-Epoch-Programs">https://github.com/apoch/epoch-language/wiki/Knowledge-Dump---Debugging-Epoch-Programs</a></div><div><br></div><div> </div></div></div></div>