[LLVMdev] llvm dwarf emission

[Duncan Sands]

Hi Nick,

> 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?

Ciao, Duncan.

  and to store that in the bitcode. In
> LLVM we would have a DwarfOpts that specifies the major version of DWARF we're
> targetting and some additional compatibility flags to work around debugger
> deficiencies.
>
> So for example, DIBuilder's interface has no createPtrToMemberType() which is
> odd since it's been there since DWARF 2, but gcc didn't emit that until very
> recently so neither does llvm. Instead clang lowers it to a difference of two
> other pointer types, which effectively throws away information. My plan is to
> always emit the bitcode with the DWARF 4 representation of a pointer to member,
> then in codegen, look at DwarfOpts.PtrToMember to decide whether to emit it as
> DW_TAG_ptr_to_member_type or the way gcc does for compatibility with older
> GDB's, etc.
>
> My premise is that storing the DWARF 4 equivalent data in the bitcode retains
> more information, so we can safely lower to another format later.
>
> Does this sound sensible?
>
> Nick
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>