The main difference is that the llvm class (just a std::vector in disguise) is not sorted. It turns out this isn't an issue because the callers either: - ignore the range list; - convert it to a different format (which is then sorted); - or query the minimum value (which is faster than sorting) The last case is something I want to get rid of in a followup as a part of removing the assumption that function's entry point is also its lowest address.
As a followup of https://github.com/llvm/llvm-project/pull/67851, I'm defining a new namespace `lldb_plugin::dwarf` for the classes in this Plugins/SymbolFile/DWARF folder. This change is very NFC and helped me with exporting the necessary symbols for my out-of-tree language plugin. The only class that I didn't change is ClangDWARFASTParser, because that shouldn't be in the same namespace as the generic language-agnostic dwarf parser. It would be a good idea if other plugins follow the same namespace scheme.
Currently, the method `GetAttributeAddressRanges` takes a DWARFRangeList as a parameter, just to immediately clear it. The method also returns the size of this list. Such an API was obfuscating the intent of the call sites (it's not clear from the method name what it returns) and it was obfuscating redundant checks on the size of the list. This commit refactors the method to return the list and to also make the call sites use the more explicit `IsEmpty` method. Differential Revision: https://reviews.llvm.org/D151451
In preparation for eanbling 64bit support in LLDB switching to use llvm::formatv instead of format MACROs. Reviewed By: labath, JDevlieghere Differential Revision: https://reviews.llvm.org/D139955
Currently, SymbolFileDWARFDebugMap works on the assumption that there is only one compile unit per object file. This patch documents this limitation (when using the general SymbolFile API), and allows users of the concrete SymbolFileDWARFDebugMap class to find out about these extra compile units. Differential Revision: https://reviews.llvm.org/D136114
LookupAddress makes no sense for DWARFTypeUnit. Also make GetNonSkeletonUnit to preserve the called type. Differential Revision: https://reviews.llvm.org/D89646
Summary: The code in DWARFCompileUnit::BuildAddressRangeTable tries hard to avoid relying on DW_AT_low/high_pc for compile unit range information, and this logic is a big cause of llvm/lldb divergence in the lowest layers of dwarf parsing code. The implicit assumption in that code is that this information (as opposed to DW_AT_ranges) is unreliable. However, I have not been able to verify that assumption. It is definitely not true for all present-day compilers (gcc, clang, icc), and it was also not the case for the historic compilers that I have been able to get a hold of (thanks Matt Godbolt). All compiler included in my research either produced correct DW_AT_ranges or .debug_aranges entries, or they produced no DW_AT_hi/lo pc at all. The detailed findings are: - gcc >= 4.4: produces DW_AT_ranges and .debug_aranges - 4.1 <= gcc < 4.4: no DW_AT_ranges, no DW_AT_high_pc, .debug_aranges present. The upper version range here is uncertain as godbolt.org does not have intermediate versions. - gcc < 4.1: no versions on godbolt.org - clang >= 3.5: produces DW_AT_ranges, and (optionally) .debug_aranges - 3.4 <= clang < 3.5: no DW_AT_ranges, no DW_AT_high_pc, .debug_aranges present. - clang <= 3.3: no DW_AT_ranges, no DW_AT_high_pc, no .debug_aranges - icc >= 16.0.1: produces DW_AT_ranges - icc < 16.0.1: no functional versions on godbolt.org (some are present but fail to compile) Based on this analysis, I believe it is safe to start trusting DW_AT_low/high_pc information in dwarf as well as remove the code for manually reconstructing range information by traversing the DIE structure, and just keep the line table fallback. The only compilers where this will change behavior are pre-3.4 clangs, which are almost 7 years old now. However, the functionality should remain unchanged because we will be able to reconstruct this information from the line table, which seems to be needed for some line-tables-only scenarios anyway (haven't researched this too much, but at least some compilers seem to emit DW_AT_ranges even in these situations). In addition, benchmarks showed that for these compilers computing the ranges via line tables is noticably faster than doing so via the DIE tree. Other advantages include simplifying the code base, removing some untested code (the only test changes are recent tests with overly reduced synthetic dwarf), and increasing llvm convergence. Tags: #lldb Differential Revision: https://reviews.llvm.org/D78489
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
Previously it was storing a *pointer*, which left open the possibility of this pointer being null. We never made use of that possibility (it does not make sense), and most of the code was already assuming that. However, there were a couple of null-checks scattered around the code. This patch replaces the reference with a pointer, making the non-null-ness explicit, and removes the remaining null-checks. llvm-svn: 363381
Summary: Type units don't represent actual compilations and a lot of the operations that we do with lldb compile units (getting their line tables, variables, etc.) don't make sense for them. There is also a lot more of them (sometimes over 100x), so making them more lightweight pays off. The main change in this patch is that we stop creating lldb CompileUnits for DWARF type units. The trickiest part here is that the SymbolFile interface requires that we assign consecutive sequence IDs to the compile units we create. As DWARF type and compile units can come in any order (in v5), this means we can no longer use 1-1 mapping between DWARF and lldb compile units. Instead I build a translation table between the two indices. To avoid pessimizing the case where there are no type units, I build the translation table only in case we have at least one type unit. Additionaly, I also tried to strenghted type safete by replacing DWARFUnit with DWARFCompileUnit where applicable. Though that was not stricly necessary, I found it a good way to ensure that the transformations I am doing here make sense. In the places where I was changing the function signatures, and where it was obvious that the objects being handled were not null, I also replaced pointers with references. There shouldn't be any major functional change with this patch. The only change I observed is that now the types in the type units will not be parsed when one calls Module::ParseAllDebugSymbols, unless they are referenced from other compile units. This makes sense, given how ParseAllDebugSymbols is implemented (it iterates over all compile units), and it only matters for one hand-writted test where I did not bother to reference the types from the compile units (which I now do). Reviewers: clayborg, JDevlieghere, aprantl Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D63005 llvm-svn: 363250