This is an archive of the discontinued LLVM Phabricator instance.

[DEBUGINFO] Add -no-dwarf-debug-ranges option.
ClosedPublic

Authored by ABataev on Mar 12 2018, 7:30 AM.

Details

Summary

Added option -no-dwarf-debug-ranges option to disable emission of
.debug_ranges section.

Diff Detail

Repository
rL LLVM

Event Timeline

ABataev created this revision.Mar 12 2018, 7:30 AM
ABataev updated this revision to Diff 138013.Mar 12 2018, 8:17 AM

Test checks updated

(& the same question as the other change, about whether this should be a per-CU flag)

test/DebugInfo/X86/no_debug_ranges.ll
4–8 ↗(On Diff #138013)

Probably worth testing what the range of this CU is rendered as, given that there are several functions in several sections, yet ranges cannot be used.

What do existing tools operating under this constraint do? (should the DWARF perhaps only describe code in the first section - rather than having (I assume this is what LLVM will produce with this patch) descriptions of several functions in several sections, but with a CU range that only covers one of those contiguous section ranges? (this might be invalid DWARF? Inaccurate ranges))

10–44 ↗(On Diff #138013)

What's interesting about these 4 sections/6 functions, more than having two sections/functions? (trying to understand what nuances are being tested here - perhaps a comment in the test case would be helpful to explain the motivation)

ABataev added inline comments.Mar 12 2018, 11:11 AM
test/DebugInfo/X86/no_debug_ranges.ll
10–44 ↗(On Diff #138013)

Nothing special, I just copied an existing test that definitely produces ranges by default. Test just checks that with the flag -no-dwarf-ranges-section no .debug_ranges section is emitted. But I agree that it would be good to test how the addresses are emitted

If you could simplify the test down to the smallest example that produces
ranges, that'd be good - which should be achievable with two functions in
distinct sections ('a' and 'b' for example).

ABataev updated this revision to Diff 138070.Mar 12 2018, 12:14 PM

Updated test checks.

dblaikie added inline comments.Mar 12 2018, 12:45 PM
test/DebugInfo/X86/no_debug_ranges.ll
1–2 ↗(On Diff #138070)

Usually debug info is tested through llvm-dwarfdump, but given the need to test for specific sections being named, testing the assembly directly's probably fine here.

4 ↗(On Diff #138070)

probably check for only .debug_ranges here? (since it's outside the debug_info section, so any mention of DW_AT_ranges wouldn't be too relevant (short of the abbrev section, but no need to check for that when you're checking for the contents of debug_info anyway, I think))

6 ↗(On Diff #138070)

probably replace ".debug_ranges" with ".section" here? (ie: make sure the low/high pc you're checking for is in the debug_info section, and make sure that section doesn't include a DW_AT_ranges)

ABataev added inline comments.Mar 12 2018, 12:49 PM
test/DebugInfo/X86/no_debug_ranges.ll
4 ↗(On Diff #138070)

There can be .debug_abbrev section with DW_AT_ranges, we need to be sure that no ranges info is generated

6 ↗(On Diff #138070)

Ok

ABataev updated this revision to Diff 138078.Mar 12 2018, 12:50 PM

Updated test checks

(& the same question as the other change, about whether this should be a per-CU flag)

Right now the idea is that we're going to want to turn off certain kinds of sections for nvptx based assembly (same as the other patch). I think we can possibly come up with dwarf/elf ways to encode this data, but in the short term let's get asm printer (and use a flag to set it up piece by piece testable) and then we can try to figure out ways to actually get the data out in the long term.

I'll let the rest of the review go as it is since it's in progress. Thanks Dave :)

-eric

Dave, some more comments?

ABataev updated this revision to Diff 139150.Mar 20 2018, 9:50 AM

Updated to latest version

dblaikie accepted this revision.Mar 20 2018, 12:29 PM

Seems OK.

Still not sure what the "right" behavior is when this is disabled, but ranges are necessary to describe the entity (like this is going to produce some odd debug info if two functions are in different sections, as shown in the test - but also cases of scopes, etc inside a function).

This revision is now accepted and ready to land.Mar 20 2018, 12:29 PM
This revision was automatically updated to reflect the committed changes.