This is an archive of the discontinued LLVM Phabricator instance.

[llvm][dwarf][rfc][donotcommit] Enable print of ranges addresses from .debug_info.dwo
Needs ReviewPublic

Authored by ayermolo on Sep 1 2023, 12:47 PM.

Details

Summary

For split dwarf some of the sections remain in the main binary. For DWARF4 it's
.debug_ranges, .debug_addr. For DWARF5 it's .debug_addr. When using
llvm-dwarfdump on .dwo/.dwp files this results in not being able to see what ranges
and addresses for DW_AT_low_pc are used in DIEs, and output having "Error: " in it.

I added a new option --main-binary=<binary> that will create a link in
DWARFContext between DWO context and main binary. This allows tool to display
addresses for DW_AT_ranges and DW_AT_low_pc.

Example (DWARF5):

DW_TAG_inlined_subroutine
        DW_AT_abstract_origin (0x00000b21 "flush_RL")
        DW_AT_ranges  (indexed (0x0) rangelist = 0x00000054
          [0x0000000000403fe2, 0x0000000000403ff3)
          [0x0000000000403ff6, 0x0000000000403ffe))

DW_TAG_subprogram
        DW_AT_low_pc  (0x0000000000403940)

Diff Detail

Event Timeline

ayermolo created this revision.Sep 1 2023, 12:47 PM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added subscribers: hoy, modimo, wenlei and 2 others. · View Herald Transcript
ayermolo requested review of this revision.Sep 1 2023, 12:47 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 1 2023, 12:47 PM
ayermolo edited the summary of this revision. (Show Details)Sep 1 2023, 12:48 PM
ayermolo added a reviewer: dblaikie.

Will add tests if the approach is acceptable.

ayermolo edited the summary of this revision. (Show Details)Sep 1 2023, 12:50 PM
ayermolo updated this revision to Diff 555499.Sep 1 2023, 1:38 PM

update from upstream branch

Might be easier to go the other way, and when dumping the main binary, also dump associated dwo/dwp files? (Perhaps under a flag, or by default, not sure)

Might be easier to go the other way, and when dumping the main binary, also dump associated dwo/dwp files? (Perhaps under a flag, or by default, not sure)

I have a patch that does this that I am going to submit soon. If you dump the main executable, if it can find the .dwo/.dwp file(s), it will dump them. I added a "--dump-dwo" option to control if we dump the .dwo file after each skeleton compile unit. I also made many options work like looking up addresses and names.

Might be easier to go the other way, and when dumping the main binary, also dump associated dwo/dwp files? (Perhaps under a flag, or by default, not sure)

From usability perspective I think this is an easier way.
--debug-info=<address> just works when dumping out .dwo or DWP file.
When dumping debug_info from random .dwo/.o files no need to copy paste the DWO ID hash to output sepcific ones.
It just works.

Might be easier to go the other way, and when dumping the main binary, also dump associated dwo/dwp files? (Perhaps under a flag, or by default, not sure)

From usability perspective I think this is an easier way.
--debug-info=<address> just works when dumping out .dwo or DWP file.
When dumping debug_info from random .dwo/.o files no need to copy paste the DWO ID hash to output sepcific ones.
It just works.

Yeah, that is something I need to add to my patch:

--dwo-id <id> --debug-info-dwo <offset>

You would need to specify the DWO ID and a "--debug-info-dwo" to dump a DIE if the main executable is specified... Both workflows seem valid IMHO

Also might be easier to explain to an "average" user "Just run llvm-dwarfdump --main-binary=<path_to_main_binary> --debug-info <path_to_dwo>" Vs Dump this DWO, look up DWOID (explain where it is in DWARF4 vs 5), then run llvm-dwarfdump again now with main binary with these flags.

@dblaikie ping. :) Do you want to continue review here or in github?

Don't mind either way - but I'm out on vacation for another week or so, so will be a little bit before I get back to this. Probably GitHub I guess?