Skip to content

[lldb][DWARF] Sort ranges list in dwarf 5. #91343

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 9, 2024

Conversation

ZequanWu
Copy link
Contributor

@ZequanWu ZequanWu commented May 7, 2024

Dwarf 5 says "There is no requirement that the entries be ordered in any particular way" in 2.17.3 Non-Contiguous Address Ranges for rnglist. Some places assume the ranges are already sorted but it's not.

For example, when parsing function info, it validates low and hi address of the function: GetMinRangeBase returns the first range entry base and GetMaxRangeEnd returns the last range end. If low >= hi, it stops parsing this function. This causes missing inline stack frames for those functions.

This change fixes it and updates the test lldb/test/Shell/SymbolFile/DWARF/x86/debug_rnglists.s so that two ranges in .debug_rnglists are out of order and image lookup -v -s lookup_rnglists is still able to produce sorted ranges for the inner block.

@ZequanWu ZequanWu requested a review from dwblaikie May 7, 2024 14:55
@ZequanWu ZequanWu requested a review from JDevlieghere as a code owner May 7, 2024 14:55
@llvmbot llvmbot added the lldb label May 7, 2024
@llvmbot
Copy link
Member

llvmbot commented May 7, 2024

@llvm/pr-subscribers-lldb

Author: Zequan Wu (ZequanWu)

Changes

Dwarf 5 says "There is no requirement that the entries be ordered in any particular way" in 2.17.3 Non-Contiguous Address Ranges for rnglist. Some places assume the ranges are already sorted but it's not. This fixes it.


Full diff: https://github.com/llvm/llvm-project/pull/91343.diff

2 Files Affected:

  • (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp (+1)
  • (modified) lldb/test/Shell/SymbolFile/DWARF/x86/debug_rnglists.s (+3-3)
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
index dabc595427df..3a57ec970b07 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
@@ -1062,6 +1062,7 @@ DWARFUnit::FindRnglistFromOffset(dw_offset_t offset) {
     ranges.Append(DWARFRangeList::Entry(llvm_range.LowPC,
                                         llvm_range.HighPC - llvm_range.LowPC));
   }
+  ranges.Sort();
   return ranges;
 }
 
diff --git a/lldb/test/Shell/SymbolFile/DWARF/x86/debug_rnglists.s b/lldb/test/Shell/SymbolFile/DWARF/x86/debug_rnglists.s
index 89b5d94c68c3..af8a1796f3ab 100644
--- a/lldb/test/Shell/SymbolFile/DWARF/x86/debug_rnglists.s
+++ b/lldb/test/Shell/SymbolFile/DWARF/x86/debug_rnglists.s
@@ -124,12 +124,12 @@ lookup_rnglists2:
 .Lrnglists_table_base0:
         .long   .Ldebug_ranges0-.Lrnglists_table_base0
 .Ldebug_ranges0:
-        .byte   4                       # DW_RLE_offset_pair
-        .uleb128 .Lblock1_begin-rnglists  #   starting offset
-        .uleb128 .Lblock1_end-rnglists    #   ending offset
         .byte   4                       # DW_RLE_offset_pair
         .uleb128 .Lblock2_begin-rnglists  #   starting offset
         .uleb128 .Lblock2_end-rnglists    #   ending offset
+        .byte   4                       # DW_RLE_offset_pair
+        .uleb128 .Lblock1_begin-rnglists  #   starting offset
+        .uleb128 .Lblock1_end-rnglists    #   ending offset
         .byte   0                       # DW_RLE_end_of_list
 .Ldebug_rnglist_table_end0:
 

@bulbazord
Copy link
Member

Some places assume the ranges are already sorted but it's not. This fixes it.

What places assumed it was sorted? I assume this means there are some bugs that this fixes? Can you give some more details about how you came to write this patch?

@ZequanWu
Copy link
Contributor Author

ZequanWu commented May 7, 2024

Some places assume the ranges are already sorted but it's not. This fixes it.

What places assumed it was sorted? I assume this means there are some bugs that this fixes? Can you give some more details about how you came to write this patch?

For example: https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp#L922-L927.
When parsing function info, it validates low and hi address of the function: GetMinRangeBase returns the first range entry base and GetMaxRangeEnd returns the last range end. If low >= hi, it stops parsing this function.

This causes missing inline stack frames for us when debugging a core dump.

@bulbazord
Copy link
Member

For example: https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp#L922-L927. When parsing function info, it validates low and hi address of the function: GetMinRangeBase returns the first range entry base and GetMaxRangeEnd returns the last range end. If low >= hi, it stops parsing this function.

This causes missing inline stack frames for us when debugging a core dump.

Gotcha, makes sense. Since you know how this fails, could you add a test to make sure that scenario continues working?

@ZequanWu
Copy link
Contributor Author

ZequanWu commented May 7, 2024

For example: https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp#L922-L927. When parsing function info, it validates low and hi address of the function: GetMinRangeBase returns the first range entry base and GetMaxRangeEnd returns the last range end. If low >= hi, it stops parsing this function.
This causes missing inline stack frames for us when debugging a core dump.

Gotcha, makes sense. Since you know how this fails, could you add a test to make sure that scenario continues working?

Yeah, I updated the test lldb/test/Shell/SymbolFile/DWARF/x86/debug_rnglists.s so that two ranges in .debug_rnglists are out of order and image lookup -v -s lookup_rnglists is still able to produce sorted ranges for the inner block:
Without this change:

         Blocks: id = {0x00000030}, range = [0x00000000-0x00000004)
         Symbol: id = {0x00000003}, range = [0x0000000000000001-0x0000000000000004), name="lookup_rnglists"

With this change:

         Blocks: id = {0x00000030}, range = [0x00000000-0x00000004)
                 id = {0x00000046}, ranges = [0x00000001-0x00000002)[0x00000003-0x00000004)
         Symbol: id = {0x00000003}, range = [0x0000000000000001-0x0000000000000004), name="lookup_rnglists"

Copy link
Member

@bulbazord bulbazord left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ZequanWu ZequanWu merged commit fdede92 into llvm:main May 9, 2024
@ZequanWu ZequanWu deleted the sort-range-list branch May 9, 2024 14:42
adrian-prantl pushed a commit to swiftlang/llvm-project that referenced this pull request May 14, 2024
Dwarf 5 says "There is no requirement that the entries be ordered in any
particular way" in 2.17.3 Non-Contiguous Address Ranges for rnglist.
Some places assume the ranges are already sorted but it's not.

For example, when [parsing function
info](https://github.com/llvm/llvm-project/blob/bc8a42762057d7036f6871211e62b1c3efb2738a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp#L922-L927),
it validates low and hi address of the function: GetMinRangeBase returns
the first range entry base and GetMaxRangeEnd returns the last range
end. If low >= hi, it stops parsing this function. This causes missing
inline stack frames for those functions.

This change fixes it and updates the test
`lldb/test/Shell/SymbolFile/DWARF/x86/debug_rnglists.s` so that two
ranges in `.debug_rnglists` are out of order and `image lookup -v -s
lookup_rnglists` is still able to produce sorted ranges for the inner
block.

(cherry picked from commit fdede92)
adrian-prantl added a commit to swiftlang/llvm-project that referenced this pull request May 14, 2024
[lldb][DWARF] Sort ranges list in dwarf 5. (llvm#91343)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants