codeview debug info in Visual Studio


Is there any way to debug the codeview output of llvm from within Visual Studio?

I want to use the codeview line info debug output of clang/llvm. I tried with the
x86_64-pc-windows-msvc and i686-pc-windows-msvc triples and linking it into an
existing project with VC++ from within the IDE and outside with link /debug.
Neither option lets me debug with Visual Studio as debugger host. With some help
I found that WinDBG does show line info, but Visual Studio does not, is there any
way to get this working with VS?


Hm, this didn’t work out of the box for me.

Make sure the debug info format is set to one of /Zi or /Z7. /ZI (capital ‘i’) is ignored, but it looks like it’s the default. We may wish to revisit that. You can find that setting in project → properties → C/C++ → debug information format.

Once I did that, I got symbols, but no line info. The source language was listed as “unknown”, so we may need to do a thing or two to make VS happy.

Hi Carlo,

Do you have VS2010 handy? It should read the DI fine.

Unfortunately, VS2013 is not able to use the debug info we generate.
It is on my plans to investigate and fix the generator, but I didn’t have enough free cycles recently.

I think I have VS2010 somewhere yes. Any hints on where to find this problem so I can try to solve it myself?

Sure, llvm/lib/CodeGen/AsmPrinter/WinCodeViewLineTables.cpp

Basically, see my patches to LLVM from early 2014 – they include tests, a DI generator and a DI dumper. I’d be happy to review your patches too!

Thanks. Looks like it’s likely that it’s one of the 0xF1 sections, the first one always has the object file name and what seems the compiler name and flags. I cloned that whole thing and it didn’t make it work. If I had to guess it would be that it’s one of the other two 0xF1 blocks but I can’t find any information on those besides the basic format (Len: UInt16, Type: UInt16, Data), these new codeview block types I can’t find at all though, at this point I’m rather stuck.

I think the problem is in the sections we already generate, not the 0xF1 ones.

Doesn’t look like it, the only thing we currently don’t do is put 0x0110, md5 hash in DEBUG_INDEX_SUBSECTION instead of the 0x00 00 00 00, I tried that and nothing happens. The line table and string table look exactly the same.