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

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

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

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 :

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?

> 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

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

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

> 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

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

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

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

I used WinDbg to show the memory protections that were placed on the executable image just after it was loaded, and just before the app starts. Here is what wine shows: View: 0x400000 - 0x765fff 28 0x400000 - 0x765fff c-rw- Here is what WinDbg shows (manually edited to look like the wine view): 0x400000 - 0x400fff c-r-- (PAGE_READONLY) 0x401000 - 0x454fff c--W- (PAGE_WRITECOPY)

Hello! After having a large feud with gdb, I decided to switch over to lldb under Windows like I already had under Linux. However, when I installed it using the 64-bit LLVM nightly installer, it kept crashing upon startup. Popping it in WinDbg (oh the irony) showed that it was trying to load Python35.dll, but it was loading the 32-bit version I had installed separately. The fix was simple:

I downloaded (shudder) Microsoft's windbg program (http://www.microsoft.com/ddk/debugging/installx86beta.asp) and ran it for the app under Win2000/VMWare. It also shows an exception at the same access! However, windbg displays the exception and then allows the user to continue the program, letting whatever exception handler the program installed handle the exception. And the program does