[llvm-dev] Gauging interest in generating PDBs from LLVM-backed languages

[Michael Lewis via llvm-dev]

On Thu, Jul 28, 2016 at 8:21 PM, Michael Lewis <don.apoch at gmail.com> wrote:
>
> I will certainly be willing to speak up if I find anything I know that
> isn't represented here already.
>


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.


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.

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.


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?



 - Mike




[0] -
https://github.com/apoch/epoch-language/wiki/Knowledge-Dump---Debugging-Epoch-Programs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160801/ec1efc87/attachment.html>