<div class="gmail_quote">On 12 September 2012 20:49, Nathan Jeffords <span dir="ltr"><<a href="mailto:blunted2night@gmail.com" target="_blank">blunted2night@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div class="gmail_quote"><div class="im">On Wed, Sep 12, 2012 at 9:46 AM, Manu <span dir="ltr"><<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>/Z7, that's the one. Maybe this approach can be used by LLVM? I presume LLVM is capable of producing CV info already? Maybe this configuration is already possible?</div>
<div>
It'd be interesting to try it out, CV in the COFF objects, and see if the linker makes sense of it at link time...</div><div><div><br></div></div></div></blockquote><div><br></div></div><div>I was able to get clang to produce COFF files with embedded DWARF debug relatively easily, which produces executables debuggable via the MinGW tool-chain.</div>
</div></blockquote><div><br></div><div><div>This sounds effectively identical to what I have now using MinGW GCC to produce COFF binaries with DWARF debug info, and then running cv2pdb after linking to extract a PDB from the binary. It works, but it means I can't link against MSVC libs/objects because of the conflicting debug info formats. :/</div>
<div><br></div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div> To support another debug format would be difficult I think, though I'm no expert on the subject. Currently LLVM internally represents everything more or less directly in DWARF. All of the debug meta-data attached to the IR is a slightly higher representation of DWARF data-structures. While there is a debug info builder class the insulates front ends from the details of DWARF to some extent, it is not complete isolation. I think the only feasible approach is to translate the DWARF info into CV info at a lower level, perhaps after the initial COFF object file containing DWARF has been emitted.</div>
</div></blockquote><div><br></div><div>Okay, so CV isn't supported, not sure where I got that idea >_<</div><div>Hmmm, okay, well I think I'm back where I started using the MinGW toolchain in that case...</div>
<div><br></div><div>Oh, it's all so problematic ;)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><div>I'd also argue that the VS debugger is possibly the single biggest productivity enhancement offered by the IDE ;)</div></div><div>And yeah, I'm in the situation where I need to link against MSVC built code, so I need PDB at the end of the day.</div>


<div><br></div><div>Your approach would be really handy in other cases though, DWARF plugin for VisualStudio would be a generally useful tool.</div></div>
</blockquote></div></div><br><div>From what I was able to gather while looking into a debugger plugin, the existing user interface would drive all debuggers, thus the user should have more or less the same debugging experience with any fully implemented plugin.</div>
</blockquote><div><br></div><div>This sounds like what WinGDB does. As I understood it, there is a problem with WinGDB, where they said they weren't able to actually implement their debugger plugin without implementing a custom project type, which mutually excludes the Visual Studio build architecture.</div>
</div>