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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp | ||
---|---|---|
55 | This isn't a valid requirement for general code. It essentially means that this code will only run for the first compile unit in an elf file (or, if type units are in use, it may not run at all). |
Could we add a test for this that either uses full-LTO in an API test or some assembler code and and lldb-test test?
lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp | ||
---|---|---|
55 | Maybe it's better to filter out skeleton units specifically instead? (If that's what the condition is for) | |
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp | ||
644 | is std::find() shorter here? | |
1276 | is std::find() shorter / more readable? | |
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h | ||
180 | nit: convert these to /// | |
181 | Why not only store a llvm::SmallVector<lldb::CompUnitSP, 1> and use the first element to store compile_unit_sp? |
Added test, changed DWARFCompileUnit::BuildAddressRangeTable to not stop looking at oso ranges at offset 0.
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp | ||
---|---|---|
644 | I think it'd be worse, because we're comparing pointers so we'd need to pass in a lambda, which would make things more confusing imo (ditto for the next comment). |
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp | ||
---|---|---|
1279 | This is technically a O(n^2) algorithm. What do you think about adding a SmallDenseMap<cu_id, cu_idx> into compile_unit_infos? | |
lldb/test/API/lang/c/full_lto_stepping/TestFullLtoStepping.py | ||
1 ↗ | (On Diff #468729) | I think this docstring looks copied&pasted? |
13 ↗ | (On Diff #468729) | You might want to mark the test as @skipUnlessDarwin since it's about debug maps. |
26 ↗ | (On Diff #468729) | If you use lldbutil.run_to_name_breakpoint I think you can delete most of the setup code? |
LGTM, with two tiny new suggestions.
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h | ||
---|---|---|
180 | IIUC, the common case is 1 unit (clang), 2 units (swift), n units (lto). Should we reserve 2 instead of one to cover the majority of use-cases? | |
182 | nit: I think we should use the same size as above llvm::SmallDenseMap<uint64_t, uint64_t, 1>, just to keep them in sync? |
This isn't a valid requirement for general code. It essentially means that this code will only run for the first compile unit in an elf file (or, if type units are in use, it may not run at all).