Added option -no-dwarf-debug-ranges option to disable emission of
.debug_ranges section.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
(& 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) |
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).
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) |
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
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).