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