On Wed, Sep 12, 2012 at 9:46 AM, Manu <turkeyman at gmail.com> wrote:> Oops, I've managed to exclude the list... > > > On 12 September 2012 19:28, Nathan Jeffords <blunted2night at gmail.com>wrote: > >> >> >> On Wed, Sep 12, 2012 at 8:50 AM, Manu <turkeyman at gmail.com> wrote: >> >>> On 12 September 2012 18:19, Nathan Jeffords <blunted2night at gmail.com>wrote: >>> >>>> This project seems to have some ability to convert to PDB, though it >>>> looks like the project stalled years ago... >>>> >>>> http://www.dsource.org/projects/visuald >>>> >>> >>> Years ago? Latest release was only 2 months ago. >>> >> >> My mistake, I was referring to cv2pdb which according the the web-page >> last had news in 2006. I had not looked in a few years. According to the >> repository, the project has not had a commit in three years. >> > > He recently added DWARF support, and serviced a couple of feature requests > for me, so it's still alive. I'm sure he'd be happy to comment/help out. > > > I have seen mention somewhere that Microsoft's link.exe is able to extract >>> CodeView debug info from COFF objects while linking to produce the final >>> PDB file... maybe there's something potentially useful in there? >>> >> cv2pdb which I mentioned above builds PDB files from both CV and DWARF >>> info contained in final binaries (PE files at least?). >>> >>> >>> Is it technically possible to put debug info in MS compatible COFF >>> objects if it behaves as you say above? How would a linker then take it and >>> produce a PDB file at link time? And does MS link.exe not do this its self? >>> Perhaps if link.exe does actually support CV in COFF, then it's just a >>> matter of writing CV to the objects, and using the MS linker to link and >>> produce the PDB file? >>> >>> >> Their are a couple of options available that allow you to embed debug >> info directly into an object file. The /Z7 (enable old-style debug info) >> option does not produce a separate PDB file, presumably this generates >> CodeView 7 information directly into the object file. The /Yd appears to >> embed addition information into the object file along with generating a >> program database, but it gives this warning when used "option 'Yd' has been >> deprecated and will be removed in a future release" >> > > /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? > 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... > >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. 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.> > >> I have on occasion got the inspiration to create a DWARF debug module >>>> for visual studio, then quickly go lost trying to get started. It looks >>>> like google has/is attempting to go down this road according to the pages: >>>> >>>> >>>> http://www.chromium.org/nativeclient/sdk/vsx-plugin/vsx-reference-material >>>> http://code.google.com/p/nativeclient/wiki/NaClDebugging >>>> >>>> though a more recent page doesn't mention visual studio: >>>> >>>> https://developers.google.com/native-client/devguide/devcycle/debugging >>>> >>>> >>> >>> It's an interesting approach, and I'd take it as a start, but it's still >>> basically a hack. Interoperability with MSVC is non-negotiable in many >>> windows projects. >>> LLVM is perhaps the closest project to salvation, this is the only real >>> limiting factor :/ >>> >>> >> I would not consider this a hack. For my own use, and I'm sure others >> would agree, I would prefer another tool chain. I just want the >> productivity enhancements I get from the Visual Studio IDE. Though I agree >> that their are projects where MS debug information is required, due to >> linking against legacy code that cannot for what ever reason me compiled >> with a different tool chain. >> > > I'd also argue that the VS debugger is possibly the single biggest > productivity enhancement offered by the IDE ;) > 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. > > Your approach would be really handy in other cases though, DWARF plugin > for VisualStudio would be a generally useful tool. >>From what I was able to gather while looking into a debugger plugin, theexisting user interface would drive all debuggers, thus the user should have more or less the same debugging experience with any fully implemented plugin. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120912/f4ffb18d/attachment.html>
On 12 September 2012 20:49, Nathan Jeffords <blunted2night at gmail.com> wrote:> > On Wed, Sep 12, 2012 at 9:46 AM, Manu <turkeyman at gmail.com> wrote: > >> /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? >> 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... >> >> > 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. >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. :/ 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. >Okay, so CV isn't supported, not sure where I got that idea >_< Hmmm, okay, well I think I'm back where I started using the MinGW toolchain in that case... Oh, it's all so problematic ;) I'd also argue that the VS debugger is possibly the single biggest>> productivity enhancement offered by the IDE ;) >> 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. >> >> Your approach would be really handy in other cases though, DWARF plugin >> for VisualStudio would be a generally useful tool. >> > > 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. >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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120912/2c4a7245/attachment.html>
On Wed, Sep 12, 2012 at 12:19 PM, Manu <turkeyman at gmail.com> wrote:> On 12 September 2012 20:49, Nathan Jeffords <blunted2night at gmail.com>wrote: > >> >> On Wed, Sep 12, 2012 at 9:46 AM, Manu <turkeyman at gmail.com> wrote: >> >>> /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? >>> 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... >>> >>> >> 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. >> > > 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. :/ > > > 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. >> > > Okay, so CV isn't supported, not sure where I got that idea >_< > Hmmm, okay, well I think I'm back where I started using the MinGW > toolchain in that case... > > Oh, it's all so problematic ;) > >It might be feasible to convert DWARF to CV within the object file prior to linking, then you should be able to link against MSVC libraries.> I'd also argue that the VS debugger is possibly the single biggest >>> productivity enhancement offered by the IDE ;) >>> 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. >>> >>> Your approach would be really handy in other cases though, DWARF plugin >>> for VisualStudio would be a generally useful tool. >>> >> >> 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. >> > > 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. >This maybe why google seems to have abandoned the idea of building a debugger plugin. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120912/0e94357b/attachment.html>