grimar added inline comments.
================
Comment at: source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.h:51-55
+ struct RngListEntry {
+ uint8_t encoding;
+ uint64_t value0;
+ uint64_t value1;
+ };
----------------
clayborg wrote:
> Do we really need to store all this? Can't we just convert to address ranges
> on the fly in DWARFDebugRngLists::Extract? With the current
> DW_RLE_base_address and DW_RLE_offset_pair stuff we can store the base
> address locally inside the DWARFDebugRngLists::Extract function and skip
> pushing an entry for it and then convert any DW_RLE_offset_pair stuff into
> addresses by adding the base address before pushing the range. Or will this
> be required to support other opcodes?
I think we can not do that in `DWARFDebugRngLists::Extract` because we should
take
in account that we can have multiple CU with different address bases.
Example:
https://github.com/llvm-mirror/lldb/blob/master/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp#L1069
In this code `dwarf2Data->DebugRanges()` call `Extract` which extracts all
ranges from `.debug_range` section.
But at the moment of extraction, it does not know the base address for a given
CU and that is why code calls
`range.Slide` after that I believe.
Here is an example I have in mind for this patch. The executable below contains
2 CUs and 2 contibution in `.debug_rnglists` (one for each CU)
```
.debug_info contents:
0x00000000: Compile Unit: length = 0x000000ac version = 0x0005 unit_type =
DW_UT_compile abbr_offset = 0x0000 addr_size = 0x08 (next unit at 0x000000b0)
0x0000000c: DW_TAG_compile_unit [1] *
...
DW_AT_low_pc [DW_FORM_addr] (0x0000000000400520)
DW_AT_high_pc [DW_FORM_data4] (0x00000034)
DW_AT_rnglists_base [DW_FORM_sec_offset] (0x0000000c)
...
0x000000b0: Compile Unit: length = 0x000000a1 version = 0x0005 unit_type =
DW_UT_compile abbr_offset = 0x00ad addr_size = 0x08 (next unit at 0x00000155)
0x000000bc: DW_TAG_compile_unit [1] *
....
DW_AT_low_pc [DW_FORM_addr] (0x0000000000400560)
DW_AT_high_pc [DW_FORM_data4] (0x00000027)
DW_AT_rnglists_base [DW_FORM_sec_offset] (0x0000001f)
```
```
.debug_rnglists contents:
0x00000000: range list header: length = 0x0000000f, version = 0x0005, addr_size
= 0x08, seg_size = 0x00, offset_entry_count = 0x00000000
ranges:
0x0000000c: [DW_RLE_offset_pair]: 0x0000000000000005, 0x0000000000000012 =>
[0x0000000000000005, 0x0000000000000012)
0x0000000f: [DW_RLE_offset_pair]: 0x0000000000000017, 0x000000000000001d =>
[0x0000000000000017, 0x000000000000001d)
0x00000012: [DW_RLE_end_of_list]
0x00000013: range list header: length = 0x0000000f, version = 0x0005, addr_size
= 0x08, seg_size = 0x00, offset_entry_count = 0x00000000
ranges:
0x0000001f: [DW_RLE_offset_pair]: 0x0000000000000005, 0x0000000000000012 =>
[0x0000000000000005, 0x0000000000000012)
0x00000022: [DW_RLE_offset_pair]: 0x0000000000000017, 0x000000000000001d =>
[0x0000000000000017, 0x000000000000001d)
0x00000025: [DW_RLE_end_of_list]
```
With that, it seems we want to parse the `.debug_rnglists` section once, but
for each CU we have different contribution offset (`DW_AT_rnglists_base`) and
the different base address (`DW_AT_low_pc`), so I think should fix up the
ranges parsed independently.
That is why I had to store `RngListEntry` list and doing the fixup in
`FindRanges`.
As an improvement we might want to cache the result returned by `FindRanges`
somehow I think, so for further calls of `FindRanges`
for a given CU we would not need to do a fixup and can just return the ranges
list built earlier.
https://reviews.llvm.org/D53140
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
