Type units go in .debug_info comdats, not .debug_types, in v5.
Details
Diff Detail
Event Timeline
I reordered the units in the test file, because llvm-dwarfdump will dump all the .debug_info bits before going on to the .debug_types bits. The order of the sections in the file doesn't matter, but the order of the CHECKs does, and this was the simplest way to deal with it.
The lld change is just to match the API change. LLD's only interest in .debug_info is so it can find the .debug_line section for reporting source info in diagnostics. It might need some finagling once we actually start emitting type units in .debug_info, because LLD wants the CU not a TU and currently it will take whatever is first.
Ping. For my next trick I was going to do the patch that emits type units in .debug_info instead of .debug_types, for DWARF v5. Would it help to have that up first?
llvm/include/llvm/DebugInfo/DWARF/DWARFObject.h | ||
---|---|---|
37 | A more common pattern in LLVM seems to be an debug_info_sections() accessor that returns an iterator range, such as in http://llvm.org/doxygen/classllvm_1_1object_1_1ObjectFile.html#a7f73649118e365a230be4870d824e7cf |
Generally looks good to me - I'll leave it to you & Adrian to hash out any concerns he has.
llvm/include/llvm/DebugInfo/DWARF/DWARFObject.h | ||
---|---|---|
37 | I don't feel very strongly about it, the iterator range just seems to be slightly more flexible as an interface. |
llvm/include/llvm/DebugInfo/DWARF/DWARFObject.h | ||
---|---|---|
37 | I did it this way to match what was in place for .debug_types; I can take an action to follow up with an iterator range. I'd rather not throw in an NFC refactor of .debug_types along with the functional part. |
A more common pattern in LLVM seems to be an debug_info_sections() accessor that returns an iterator range, such as in http://llvm.org/doxygen/classllvm_1_1object_1_1ObjectFile.html#a7f73649118e365a230be4870d824e7cf