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

[Hal Finkel via llvm-dev]

----- Original Message -----

> From: "Michael Lewis via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Johan Wehrli" <johan.wehrli at strong.codes>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Monday, August 1, 2016 4:01:57 PM
> Subject: Re: [llvm-dev] Gauging interest in generating PDBs from
> LLVM-backed languages

> 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.
You might also find this useful: https://github.com/Microsoft/microsoft-pdb 

-Hal 

> 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

> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160801/8ce09de0/attachment-0001.html>