llvm dev - Aug 2016 - Gauging interest in generating PDBs from LLVM-backed languages

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).
>
> You can modify the line "set(MSVC_DIA_SDK_DIR
"$ENV{VSINSTALLDIR}DIA
> SDK”)” by "set(MSVC_DIA_SDK_DIR “C:\\path\\to\\DIA SDK”)”.
>
>
Awesome, that did the trick - thanks!

It turns out I was running CMake without the VS Environment vars set, so
%VSINSTALLDIR% was empty. Running with the environment set up correctly
fixed the problem.



On Tue, Jul 26, 2016 at 7:56 PM, Zachary Turner <zturner at google.com>
wrote:
> Even if you don't have DIA SDK, llvm-pdbdump will still work with the
> "raw" subcommand, just not the "pretty" subcommand.
>
I was running a 3.8 install where this functionality had apparently not yet
landed. I pulled a fresh install from trunk earlier and I'm now playing
around with "raw". So far this looks immensely promising and probably
well
beyond my own scope of familiarity with the PDB/MSF formats. I didn't
realize that this much progress had been made since 3.8; serves me right I
guess for not looking at trunk sooner!


I will certainly be willing to speak up if I find anything I know that
isn't represented here already.



 - Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160728/8e8593b7/attachment.html>

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>

----- 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>