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, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120628/6f236aef/attachment.html>
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 >
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? -- cheers, --renato http://systemcall.org/
On Jun 28, 2012, at 1:25 AM, Nick Lewycky 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, 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?Yep. Sounds fine. The current MD layout is very tied to dwarf as it is. A new format is possible, but would need to be new and this is just an extension of the existing format. -eric