> To make it possible to quickly see whether an address (range) is covered > by an ELF file containing DWARF information two proposals were made: > > aranges does not have debug info length > http://dwarfstd.org/ShowIssue.php?issue=100430.1 > > debug_aranges and address-less CUs > http://dwarfstd.org/ShowIssue.php?issue=100430.2
We dropped the first and made the second a best practice. > But then there are also the following proposals: > > Type Unit Merge > http://dwarfstd.org/ShowIssue.php?issue=130526.1 Yes, this is pretty much why we dropped the first proposal. > Ambiguity in DWARF4 of debug_info_offset in .debug_aranges > http://dwarfstd.org/ShowIssue.php?issue=100816.1 I don't see how this one is relevant. This was really just an editorial change -- .debug_aranges physically could not point to a .debug_types section. In addition, with the type unit merge proposal, it becomes completely irrelevant (there will be no .debug_types section at all). > One way might be to reverse the last proposal. Instead of removing the > aranges for type units (which did indeed not make much sense in the > split .debug_info/.debug_type approach), add an empty aranges header if > a type unit appears in .debug_info in the way of the second proposal for > address-less CUs. I don't really like the idea of having aranges sections for type units. It would be nicer to keep type units separate, since there are *so* many more of them than there are compunits, but for the accelerator table proposal, we needed a unified address space for the two, and this was the simplest way to accomplish that. I think it's fine for a consumer to first assume that the .debug_aranges table is complete, but if an address lookup fails, then it can scan the .debug_info section, hopping from one CU/TU to the next, looking for CUs that aren't covered by .debug_aranges tables. Having the debug_info length field in the aranges table would help, but even then, it's not clear to me how much it will help. With unified CUs and TUs, this scan will be costly with or without the length field -- for every CU, you'll probably have to skip over dozens or hundreds of TUs. It might help if we could guarantee that all CUs precede all TUs, but the only reasonable way to do that is to keep them in separate sections to begin with! Adding empty aranges tables for the TUs will bloat the .debug_aranges section significantly, and it would add a burden on the producers to make sure that the .debug_aranges contributions are in the same COMDAT group as the TU itself (GCC, for example, still doesn't put related sections in the same group). I think if we can come up with a way to have index entries in the accelerator tables point to either a CU or a TU without having a unified address space, we wouldn't need to merge .debug_info and .debug_types, and we could reopen the first proposal. -cary _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
