This is an archive of the discontinued LLVM Phabricator instance.

Fix .debug_aranges parsing issues introduced with llvm error handling in LLDB
ClosedPublic

Authored by clayborg on Mar 26 2021, 1:11 AM.

Details

Summary

When LLVM error handling was introduced to the parsing of the .debug_aranges it would cause major issues if any DWARFDebugArangeSet::extract() calls returned any errors. The code in DWARFDebugInfo::GetCompileUnitAranges() would end up calling DWARFDebugAranges::extract() which would return an error if _any_ DWARFDebugArangeSet had any errors, but it default constructed a DWARFDebugAranges object into DWARFDebugInfo::m_cu_aranges_up and populated it partially, and returned an error prior to finishing much needed functionality in the DWARFDebugInfo::GetCompileUnitAranges() function. Subsequent callers to this function would see that the DWARFDebugInfo::m_cu_aranges_up was actually valid and return this partially populated DWARFDebugAranges reference _and_ it would not be sorted or minimized.

This above bugs would cause an incomplete .debug_aranges parsing, it would skip manually parsing any compile units for ranges, and would not sort the DWARFDebugAranges in m_cu_aranges_up.

This bug would also cause breakpoints set by file and line to fail to set correctly if a symbol context for an address could not be resolved properly, which the incomplete and unsorted DWARFDebugAranges object that DWARFDebugInfo::GetCompileUnitAranges() returned would cause symbol context lookups resolved by address (breakpoint address) to fail to find any DWARF debug info for a given address.

This patch fixes all of the issues that I found:

  • DWARFDebugInfo::GetCompileUnitAranges() no longer returns a "llvm::Expected<DWARFDebugAranges &>", but just returns a "const DWARFDebugAranges &". Why? Because this code contained a fallback that would parse all of the valid DWARFDebugArangeSet objects, and would check which compile units had valid .debug_aranges set entries, and manually build an address ranges table using DWARFUnit::BuildAddressRangeTable(). If we return an error because any DWARFDebugArangeSet has any errors, then we don't do any of this code. Now we parse all DWARFDebugArangeSet objects that have no errors, if any calls to DWARFDebugArangeSet::extract() return errors, we skip that DWARFDebugArangeSet so that we can use the fallback call to DWARFUnit::BuildAddressRangeTable(). Since DWARFDebugInfo::GetCompileUnitAranges() needs to parse what it can from the .debug_aranges and build address ranges tables for any compile units that don't have any .debug_aranges sets, everything now works as expected.
  • Fix an issue where a DWARFDebugArangeSet contains multiple terminator entries. The LLVM parser and llvm-dwarfdump properly warn about this because it happens with linux compilers and linkers and was the original cause of the bug I am fixing here. We now correctly warn about this issue if "log enable dwarf info" is enabled, but we continue to parse the DWARFDebugArangeSet correctly so we don't lose data that is contained in the .debug_aranges section.
  • DWARFDebugAranges::extract() no longer returns a llvm::Error because we need to be able to parse all of the valid DWARFDebugArangeSet objects. It also will correctly skip a DWARFDebugArangeSet object that has errors in the middle of the stream by setting the start offsets of each DWARFDebugArangeSet to be calculated by the previous DWARFDebugArangeSet::extract() calculated offset that uses the header which contains the length of the DWARFDebugArangeSet. This means if do we run into real errors while parsing individual DWARFDebugArangeSet objects, we can continue to parse the rest of the validly encoded DWARFDebugArangeSet objects in the .debug_aranges section. This will allow LLDB to parse DWARF that contains a possibly newer .debug_aranges set format than LLDB currently supports because we will error out for the parsing of the DWARFDebugArangeSet, but be able to skip to the next DWARFDebugArangeSet object using the "DWARFDebugArangeSet.m_header.length" field to calculate the next starting offset.

Tests were added to cover all new functionality.

Diff Detail

Event Timeline

clayborg requested review of this revision.Mar 26 2021, 1:11 AM
clayborg created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptMar 26 2021, 1:11 AM
clayborg retitled this revision from Fix .debug_aranges parsing issues. to Fix .debug_aranges parsing issues introduced with llvm error handling in LLDB.Mar 26 2021, 1:14 AM
clayborg added subscribers: aadsm, wallace.

(generally makes sense to me - but I'll leave it to some more lldb-focussed reviewers to do more review/approval)

Usual caveat/question: Does this take us closer or further away from unifying this code with LLVM's libDebugInfoDWARF? (or neutral)

lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.cpp
56

This maths seems strange - the m_offset ... - m_offset cancel each other out, right?

(generally makes sense to me - but I'll leave it to some more lldb-focussed reviewers to do more review/approval)

Usual caveat/question: Does this take us closer or further away from unifying this code with LLVM's libDebugInfoDWARF? (or neutral)

It is neutral right now, maintains the current separation.

lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.cpp
56

Math is good. We are adding the number of bytes that were used to encode the length (4 or 12) by saying:

m_offset + <length of length encoding> + m_header.length
JDevlieghere added inline comments.Mar 26 2021, 11:44 AM
lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.h
19–33

Nit: Can you put these above the members (because of the 80 col limit) and make them Doxygen comments (///)?

50

dw_offset_t?

lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugAranges.cpp
63–67

Nit: I would phrase this as an example rather than in terms of what the old code did.

clayborg updated this revision to Diff 333639.Mar 26 2021, 3:06 PM

Fix issues found by JDevlieghere.

clayborg marked 3 inline comments as done.Mar 26 2021, 3:07 PM
dblaikie added inline comments.Mar 26 2021, 3:07 PM
lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.cpp
56

The net effect ends up a bit convoluted & I think it'd be (at least I'd find it) easier to read as *offset_ptr + m_header.length

clayborg added inline comments.Mar 26 2021, 3:08 PM
lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.cpp
56

Ah yes! I will change it.

clayborg updated this revision to Diff 333640.Mar 26 2021, 3:10 PM

Simplify expression for calculating the m_next_offset.

I'd love to get this in as this affects many of our clients. Does anyone else have an issues with this?

This revision is now accepted and ready to land.Mar 29 2021, 3:31 PM
This revision was landed with ongoing or failed builds.Mar 29 2021, 3:34 PM
This revision was automatically updated to reflect the committed changes.
yinghuitan added inline comments.
lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.cpp
96

Unrelated, but I think 2 * m_header.addr_size is more readable considering compiler would optimize it into bit shifting anyway.

98–99

Unrelated to this diff, but I find this simple round up can be shorten to:

first_tuple_offset = ((header_size + tuple_size - 1) / tuple_size) * tuple_size;
134–135

Maybe add a TODO for "We also could watch out for multiple entries at address zero and remove those as well" since we did not do it here?

lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.h
61

Do you mind add comment to explain this field? It is not very clear that it points to the section offset after this .debug_aranges set. Also, maybe it is more meaningful rename it to m_set_end_offset?

clayborg added inline comments.Mar 29 2021, 4:11 PM
lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.cpp
96

I agree and these kinds of NFC fixes can easily be checked in without review if you want to commit them.

99

True, and an NFC commit can be made if you want to take that on.

135

The problem is that we might have a .o file that does have a valid function at address zero. Since these descriptors are not sorted it would be inefficient to check for multiple entries with address zero. The problem is that linkers really shouldn't be picking address zero as the tombstone value for "I didn't have a location for this address". An address of UINT64_MAX (-1) would be better and would be easier to see if this is incorrect. The way that GSYM does this is it figures out what the valid section ranges are for executable sections and only accepts address ranges that are in those valid executable ranges. We have some patches to the DWARF parser that tried to go this from Antonio I believe, but I am not sure they ever got resolved and checked in. It is quite a problem though, but should be solved in a separate patch.

lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugArangeSet.h
61

It is the offset of the next DWARFDebugArangeSet. I can add a comment in a follow up patch.