Teaches llvm-dwarfdump to print section index and name of range
when it dumps .debug_info.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/DebugInfo/DWARF/DWARFDie.cpp | ||
---|---|---|
64 ↗ | (On Diff #109741) | I think I would prefer an empty string instead of "N/A". |
Thanks a bunch for working on this - I reckon it's a great direction!
lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
1044 ↗ | (On Diff #109741) | If/how do section indexes work in this codepath? Are they provided & printed but without names (because the section itself cannot be looked up)? Is there a way to support that? (probably not necessary, but consistency is nice where it's possible) |
1194–1200 ↗ | (On Diff #109741) | Maybe invert this for an early return: if (!Obj) return ""; return std::next(Obj->sections(), Index)->getName(Ret); |
lib/DebugInfo/DWARF/DWARFDie.cpp | ||
64–67 ↗ | (On Diff #109741) | Rather than creating a temporary string, maybe move this to after the format line, and print it directly to the stream with a format call as well? |
test/DebugInfo/X86/dwarfdump-ranges-unrelocated.s | ||
7–8 ↗ | (On Diff #109741) | It'd be nice to columnize the section number - but maybe that's too much work? (scanning through to find the longest section name, etc) Also, similar amount of work: Do you think it'd be worth it/good to omit the section number if the section names are not ambiguous in this list? (or perhaps necessary to only do this if the name is not ambiguous in the whole file (so you on't look at the ranges for two functions and see them describing what appears to be the same section)) & what about omitting the name or putting it somewhere else (like at the start on a separate line) if every entry is in the same section? (which will be the case for all ranges except the compile_unit ranges, most likely) Maybe that's all overkill - wouldn't mind getting Adrian's take on this, as he was driving a bunch of the dwarfdump improvements like this inline range dumping. |
test/DebugInfo/dwarfdump-ranges.test | ||
7–8 ↗ | (On Diff #109741) | Why does this print N/A in this test case? |
- Addressed review comments.
lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
1044 ↗ | (On Diff #109741) | Currently I think only 2 tools use DIContext::dump() call: llvm-dwarfdump and llvm-objdump, But that is not so simple to implement because currently we take SectionIndex from relocations and Fortunately tools do not need it. I would leave this place as is. |
1194–1200 ↗ | (On Diff #109741) | Done. |
lib/DebugInfo/DWARF/DWARFDie.cpp | ||
64 ↗ | (On Diff #109741) | Done. |
64–67 ↗ | (On Diff #109741) | Done. |
test/DebugInfo/X86/dwarfdump-ranges-unrelocated.s | ||
7–8 ↗ | (On Diff #109741) | I would not scan over all sections of file, because it looks too much. Scanning over all sections can be slow. Also I think often I am looking for section number in readelf/objdump/other tools, so I would not omit Basing on above I think I like "omitting the name or putting it somewhere else (like at the start on a separate line) if every entry is in the same section" as it avoids printing the same name+index multiple times. What do you think about new version of output ? (I am wondering if we still want to columnize the section index, I am not sure). |
test/DebugInfo/dwarfdump-ranges.test | ||
7–8 ↗ | (On Diff #109741) | dwarfdump-test4.elf-x86-64 is not an object but DSO. It does not have .rel[a] sections |
Changed inplementation.
- Do not print section/index when -brief=true
- Do not print section index when name is unique.
I am not sure last one worth all the code complication it requires,
I would probably just pring section index always. Though
such approach has its own benefits, so I think I am fine with it.
Looks OK to me - though please refactor the section name/uniqueness gathering so it's done once (probably lazily) rather than every time a range is dumped.
lib/DebugInfo/DWARF/DWARFDie.cpp | ||
---|---|---|
60–71 ↗ | (On Diff #110339) | Presumably this shouldn't be computed for each range that's dumped? Maybe a lazy accessor on DWARFContext that populates the list the first time it's called? |