[LLVMdev] PDB debug info

[Nathan Jeffords]

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, 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120912/f4ffb18d/attachment.html>