I plan on replacing LLDB's DWARFUnitHeader implementation with LLVM's.
LLVM's DWARFUnitHeader::extract applies the DWARFUnitIndex::Entry to a
given DWARFUnitHeader outside of the extraction because the index entry
is only relevant to one place where we may parse DWARFUnitHeaders
(specifically when we're creating a DWARFUnit in a DWO context). To ease
the transition, I've reshaped LLDB's implementation to look closer to
LLVM's.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I'm not exactly familiar with DWOs, but the code motions LGTM!
lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp | ||
---|---|---|
882 | If LLVM's function is like this as well, we shouldn't do anything now and just refactor it later once we make the switch. But a pointer parameter in a function that asserts not null immediately is more expressive as a reference. Note that, in the code where this is called, we have a: if (ptr) ApplyIndex(ptr) So the assert is not needed, as the callee respects the contract and can do a *ptr |
lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp | ||
---|---|---|
882 | Yes, this was my thought process as well. I wrote it this way because LLVM's function is just like this. I'm also touching that equivalent function in LLVM in a different way (adding error handling, see https://reviews.llvm.org/D151933). Let's rework this in a follow-up? |
If LLVM's function is like this as well, we shouldn't do anything now and just refactor it later once we make the switch. But a pointer parameter in a function that asserts not null immediately is more expressive as a reference. Note that, in the code where this is called, we have a:
So the assert is not needed, as the callee respects the contract and can do a *ptr