[LLVMdev] PDB debug info

[Manu]

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