similar to: 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). > >

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

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

On Tue, Jul 26, 2016 at 12:30 PM, Zachary Turner <zturner at google.com> wrote: > I wrote most of the pdb code in llvm so far. As Reid suggested, if you > look in DebugInfo/PDB/Raw there is a significant amount of code dealing > with msf files and raw pdb streams. If you build the llvm-pdbdump tool you > can run it with the "raw" subcommand to dump lots of low level

I've always just hacked support for this in to the various JITs (for JuliaLang, in our debuginfo.cpp file), by setting the no-frame-pointer-optim flag in the IR, then creating and populating a dummy unwind description object in the .text section, and registering that dynamically. Some day I hope to actually just register the .pdata/.xdata sections with the unwinder. PDBs are a bit different

Folks, We are contemplating holding a Birds of a Feather session titled "Julia and LLVM: Implementing a fast dynamic language for technical computing" at the LLVM 2012 European Conference on April 12-13 in London. http://llvm.org/devmtg/2012-04-12/ Would this be of interest to the LLVM developer and user community? It would be great if you could drop me a line. It will help us gauge

Hi, I'm using IR and MCJIT to compile a script language. I debug it with on the fly generated .pdb files. During debugging, almost each time I step into a function, I loose information about calling function inside the visual studio callstack view or I have a bunch of pure addresses in the callstack in between the current function and the calling function, for example :

What is the status of debuginfo-tests? Is it actively supported? How do you run it? It doesn't appear to be based on lit, any particular reason? Why is it its own repo instead of being part of llvm repo? I'd like improve this to support CodeView and PDB, such that it would only run on Windows and only if a suitable debugger was found (probably WinDbg). WinDbg supports a

As executable tests, they fail spectacularly in a cross-build environment. And you need some sort of debugger with GDB-like commands and output (or have some front end to your debugger that imitates that) in order to run them. I think they would need to stay in a separate project because of those requirements. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David

> On Sep 7, 2017, at 11:37 AM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > To be clear, the tests I'm proposing will have no resemblance whatsoever to GDB, so I would be intentionally forking the set of tests in this regards. So there would very clearly be a paradigm shift in writing CodeView debug info tests (which would be written in JavaScript using

> On Sep 7, 2017, at 12:01 PM, Zachary Turner <zturner at google.com> wrote: > > > > On Thu, Sep 7, 2017 at 11:49 AM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: >> On Sep 7, 2017, at 11:37 AM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> To

On Thu, Oct 29, 2015 at 12:42 PM, Daniel Dilts via cfe-dev < cfe-dev at lists.llvm.org> wrote: > 2. Will LLD and LLDB be updated as necessary to support CodeView? > Rui is is looking at making LLD link codeview from object files into PDBs. Zachary Turner intends to add PDB reading support to LLDB. We already have a PDB implementation of DIContext in lib/DebugInfo that uses PDBs. The

Even if it were under llvm, that doesn't mean it would have to be part of ninja check-all. Currently we have lldb/test and lldb/unittests, what about a third lldb/dbgtests? Then you could run it as ninja check-dbgtest. Although now that I think about it, we would want it to be able to invoke clang-cl directly, so I guess that does necessitate it *not* being under llvm. On Thu, Sep 7, 2017

That's true, but it still requires the person writing the test to be familiar with both formats. Also anything more trivial than dumping a single local variable will probably run into even more issues. For example, The expression parsers each have their own unique quirks, and it might not always be easy to translate. Besides all the format compatibility issues, there's the more general

Hi Zach (or anyone else who may have a clue), I'm currently investigating making use of LLVM for PDB parsing for with a view to supporting partial PDBs as produced by /DEBUG:FASTLINK as the VS DIA SDK hasn't been updated to handle them. I know this is probably low on your priority list but since /DEBUG:FASTLINK is now the implied default for VS2017 I figure it's a good time to take a

Hello, I have been struggling with WinDbg/Kd for the last week, but to no avail... So I finally decided to ask here. Basically, I am using a Windows XP virtual machine (thanks to VMWare6) and wanted to do some kernel debugging using Windbg. So, I did configure everything from the virtual machine side (using this guide: http://silverstr.ufies.org/lotr0/windbg-vmware.html), and then tried my hands

Hi, Is there any way to debug the codeview output of llvm from within Visual Studio? I want to use the codeview line info debug output of clang/llvm. I tried with the x86_64-pc-windows-msvc and i686-pc-windows-msvc triples and linking it into an existing project with VC++ from within the IDE and outside with link /debug. Neither option lets me debug with Visual Studio as debugger host.

RFC: CodeView debug info emission in Clang/LLVM Overview On Windows, the de facto debug information format is CodeView, most commonly encountered in the form of a .pdb file. This is the format emitted by the Visual C++, C#, and VB.NET compilers, consumed by the Visual Studio debugger and the Windows debugger (WinDbg), and exposed for read-only access via the DIA SDK. The CodeView format has never

hi, I am using xen-unstable version and I can use the serial port to debug DomU openSuSE Linux with kgdb very well. But it doesn''t work when I am trying to debug DomU WinXP with windbg. I happened to find this link http://www.evilbitz.com/2006/12/13/howto-debugging-a-remote-windows-hvm-under-xen-using-windbg/, but it still doesn''t work for me. Any suggestions about this?

Hey all, I plan to use windbg tool to do remote debug my Windows PV Driver. I''m confused how to setup the enviroment. Any Advice? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users