Page MenuHomePhabricator

[llvm-dwarfdump] - Add the support of parsing .debug_loclists.
ClosedPublic

Authored by grimar on Oct 17 2018, 3:58 AM.

Details

Summary

This teaches llvm-dwarfdump to dump the content of .debug_loclists sections.

It converts the DWARFDebugLocDWO class to DWARFDebugLoclists,
teaches llvm-dwarfdump about .debug_loclists section and
adds the implementation for parsing the DW_LLE_offset_pair entries.

Diff Detail

Repository
rL LLVM

Event Timeline

grimar created this revision.Oct 17 2018, 3:58 AM
grimar updated this revision to Diff 170066.Oct 18 2018, 5:14 AM
grimar edited the summary of this revision. (Show Details)
  • Use base address when dumping the DW_LLE_offset_pair.
  • Added support for dwarf::DW_LLE_start_length and dwarf::DW_LLE_base_address.

+wolfgang who has been working in this area also

echristo accepted this revision.Oct 19 2018, 5:29 PM

LGTM. This code needs a lot of cleanup, but that's for another day.

This revision is now accepted and ready to land.Oct 19 2018, 5:29 PM
This revision was automatically updated to reflect the committed changes.
dblaikie added inline comments.Oct 22 2018, 11:48 AM
lib/DebugInfo/DWARF/DWARFDebugLoc.cpp
222–226 ↗(On Diff #170066)

This should lookup Value0 in the address pool, probably? I think I have that implemented for rnglists in my prototype/work-in-progress work there. (nothing I've sent out yet, but should be soon)

238–240 ↗(On Diff #170066)

Probably worth implementing base_addressx too

llvm/trunk/lib/DebugInfo/DWARF/DWARFDebugLoc.cpp
161

Looks like this should probably be a ULEB128 too, according to DWARF5?

(2.6.2 Location Lists - DW_LLE_startx_length: "This is a form of bounded location description that has two unsigned ULEB operands. The first value is an address index (into the .debug_addr section) that indicates the beginning of the address range over which the location is valid. The second value is the length of the range. ")

grimar added inline comments.Oct 22 2018, 11:58 AM
lib/DebugInfo/DWARF/DWARFDebugLoc.cpp
222–226 ↗(On Diff #170066)

Probably. That is also was the original code.

llvm/trunk/lib/DebugInfo/DWARF/DWARFDebugLoc.cpp
161

Yes, it was in my to-do list. That is the original code. I had no chance to prepare the test case + patch to fix it yet.

I just wanted to let you know that I am currently working on a patch to refactor some of the rangelists code (see: https://reviews.llvm.org/D51081) with the objective to

  1. fold the pre-v5 functionality (.debug_ranges) into DWARF5 so we can get rid of DebugRangelists.{cpp,.h}
  2. templatize more of the DWARFListTable usage so it could be also used for location lists

Unfortunately the first submission attempt caused some problems with TSan tests that I don't have access to, so there is still some work to be done. Once I'm past this I would like to suggest basing the location list table handling on the same framework, if you are OK with that.

I just wanted to let you know that I am currently working on a patch to refactor some of the rangelists code (see: https://reviews.llvm.org/D51081) with the objective to

  1. fold the pre-v5 functionality (.debug_ranges) into DWARF5 so we can get rid of DebugRangelists.{cpp,.h}
  2. templatize more of the DWARFListTable usage so it could be also used for location lists

    Unfortunately the first submission attempt caused some problems with TSan tests that I don't have access to, so there is still some work to be done. Once I'm past this I would like to suggest basing the location list table handling on the same framework, if you are OK with that.

Sounds good to me :)

-eric

I just wanted to let you know that I am currently working on a patch to refactor some of the rangelists code (see: https://reviews.llvm.org/D51081) with the objective to

  1. fold the pre-v5 functionality (.debug_ranges) into DWARF5 so we can get rid of DebugRangelists.{cpp,.h}
  2. templatize more of the DWARFListTable usage so it could be also used for location lists

    Unfortunately the first submission attempt caused some problems with TSan tests that I don't have access to, so there is still some work to be done. Once I'm past this I would like to suggest basing the location list table handling on the same framework, if you are OK with that.

Sounds good, thanks!