[LLVMdev] llvm dwarf emission

[Nick Lewycky]

Duncan Sands wrote:
> On 28/06/12 11:29, Renato Golin wrote:
>> On 28 June 2012 10:15, Duncan Sands<baldrick at free.fr>  wrote:
>>>> I wanted to check that I'm headed in the right direction before I work more on
>>>> LLVM debug info. What I'd like to do is update DIBuilder to expose exactly the
>>>> facilities represented in modern DWARF,
>>>
>>> wouldn't it be better in the long term to make the debug info layer more
>>> abstract rather than a direct mapping onto dwarf?
>>
>> And to have a Dwarf/COFF layers on top?
>
> And have the code generators output the appropriate dwarf or whatever.

There's a good split of responsibilities between what's in the .bc file 
and what llvm has to output. We simply use the dwarf numberings to 
indicate things like "this is a pointer type" and the type hierarchy and 
the hierarchy of line numbers in files and function ("subprograms") 
etc., while leaving llvm to do the work of encoding how instructions map 
to line numbers or how to recompute the value in a variable from 
registers/memory.

I don't see any reason we can't store DWARF in the bitcode and then 
lower it to anything else later, even STABS if you want.

The reason for using dwarf is that it's very expressive (it's likely 
that anybody who is interested in debug info is working/has worked with 
the dwarf committee to get the necessary extensions into dwarf) and we 
don't need to invent our own language.

Which leads to my next point, if you want us to emit to an abstract 
layer on top, please propose a spec for that system, and be sure to 
explain why it's better than just using dwarf.

The sort of thing I'd like to fix is that we currently don't allow 
encoding some data, even if dwarf allows it, just because it couldn't be 
expressed in C or C++, so clang didn't need it. For example, DWARF 
permits all types to have names. In C++, "int&" can't have a name (you 
can have a typedef to it, but that's a separate type declaration), so 
the API in DIBuilder createReferenceType simply hard-codes NULL in the 
name field. Unlike createClassType, which does take a Name parameter. 
That's silly, and we should stop that; we should actually expose the 
functionality available in DWARF. LLVM is useful for languages other 
than C/C++.

Nick