This is an archive of the discontinued LLVM Phabricator instance.

[DWARF v5] Don't emit duplicate DW_AT_rnglists_base and address review comments from previous review
ClosedPublic

Authored by wolfgangp on Jul 18 2018, 4:44 PM.

Details

Summary

This is a follow-on to https://reviews.llvm.org/D49214, which received some additional review comments after closing.

Addresses the following:

  1. Fixing a bug with duplicate emission of DW_AT_rnglists_base with test case.
  2. Fixing a somewhat stale comment to constructSkeletonCU() and moving it to the header.
  3. Refactor DwarfDebug::emitDebugRanges() to handle both v5 and prior.
  4. Some minor grammatical tweaks.

Dave already handled the base address specifier issues mentioned in the other review, as well as some test coverage additions in a different revision. Thanks!

Diff Detail

Repository
rL LLVM

Event Timeline

wolfgangp created this revision.Jul 18 2018, 4:44 PM
JDevlieghere added inline comments.Jul 19 2018, 3:04 AM
lib/CodeGen/AsmPrinter/DwarfDebug.cpp
2068 ↗(On Diff #156177)

Can we simplify this by returning a MCSymbol* instead?

Review comments: Have emitRnglistsTableHeader() return the end symbol instead of setting it as a reference parameter.

Found a problem with the fix to duplite emission of DW_AT_rnglists_base and corrected it. Apologies.

lib/CodeGen/AsmPrinter/DwarfDebug.cpp
2068 ↗(On Diff #156177)

Yes, I was a bit hesitant to return something from a function called 'emit' but it's simpler that way.

dblaikie added inline comments.Jul 19 2018, 1:38 PM
lib/CodeGen/AsmPrinter/DwarfDebug.cpp
788 ↗(On Diff #156330)

This doesn't look like the right place to add the rnglists_base - it's possible for there to be ranges without the CU itself having ranges. (eg: a CU could have one function containing one scope - the CU would have a low/high pc (not ranges) but would still need rnglists_base so the scope could use rnglistx), I think?

So it probably can be pulled out of this conditional (& a test case added to cover/demonstrate this situation)

2103–2106 ↗(On Diff #156330)

Probably drop the extra () around the return expression?

2140–2141 ↗(On Diff #156330)

Rather than testing the dwarf version and then asserting table end, maybe just use TableEnd as the test:

if (TableEnd)
  Asm->OutStreamer->EmitLabel(TableEnd);
test/DebugInfo/X86/rnglists_base_attr.ll
9 ↗(On Diff #156330)

total side note: (& I stumbled across the same code sample as you did here while making some range tests) this code probably shoudln't produce a DW_AT_ranges at -O0. For some reason the bool initialization is done inside the new/nested scope (which seems good/proper/correct) but the boolean test is not (which seems a bit weird/bogus)...

Fine for this test case (though I'd tend to err on the side of something a bit more intentional, though it's more work - like introducing a scope & then manually reordering some instructions to introduce a "hole" & force ranges to be used) because even if clang is fixed, the IR here will remain as-is.

wolfgangp updated this revision to Diff 156418.Jul 19 2018, 7:03 PM
wolfgangp marked 4 inline comments as done.

Addressed review comments wrt correctly adding DW_AT_rnglists_base and associated test cases. More details inline.

lib/CodeGen/AsmPrinter/DwarfDebug.cpp
788 ↗(On Diff #156330)

Right. All CU ranges are added to the range list vector by attachRangesOrLowHighPC() (unless the CU just uses low/high so we can use the size of the vector to decide whether to add the attribute.

There seem to be 3 distinct cases:

  • at least one scope range: requires a range list table (and hence the attribute), even if there is only one CU range. This is covered by fission-ranges.ll
  • otherwise, if there is more than one CU range, we need a table & attribute. The new test case rnglists_curanges.ll covers this.
  • if there is only one CU range, no list or attribute is needed. This is covered by a mod to cu-ranges.ll
test/DebugInfo/X86/rnglists_base_attr.ll
9 ↗(On Diff #156330)

I modified the test like you suggested. Not that much work, really.

Is this still missing test coverage for the case where the CU has low/high_pc, but also needs a ranges_base because a function has ranges for a local scope? Looks like the bug got fixed, but test coverage is still missing?

test/DebugInfo/X86/rnglists_base_attr.ll
4 ↗(On Diff #156418)

Maybe expound on this a bit more:

"... in the CU DIE when more than one range list is emitted."

To help explain why the source example code looks the way it does - maybe include some comment about "force a non-contiguous local-scope DIEs for f1 and a non-contiguous CU by having functions in different sections" or the like.

(I know I'm really bad at commenting test cases & explaining why they're constructed the way they are - so this is more a "do as I say, not as I do" - but also please do poke me about doing this myself when I'm a bit opaque in my test cases!)

4–5 ↗(On Diff #156418)

I'd probably introduce a separate f1/f2 - so that it doesn't look like the recursion is an integral part of the test:

void f1();
void f2() {
  f1(); //reorder the IR for this call between the two below to produce ranges
  {
    bool b; // force a DW_AT_lexical_scope to be created
    f1();
    f1();
  }
}

Is this still missing test coverage for the case where the CU has low/high_pc, but also needs a ranges_base because a function has ranges for a local scope? Looks like the bug got fixed, but test coverage is still missing?

This case is covered by the modified fission-range.ll in https://reviews.llvm.org/D49214. It's technically not a fission test case, but it was a convenient place to put it. I can pull it out if you like, or perhaps add a simpler test case.

wolfgangp updated this revision to Diff 157145.Jul 24 2018, 3:39 PM
  • Elaborated more on the rationale of the test case rnglists_base_attr.ll and used a simpler test case suggested by Dave.
  • adjusted the spelling of some dump strings in a test.
dblaikie accepted this revision.Jul 24 2018, 4:27 PM

Looks good! thanks for your patience!

This revision is now accepted and ready to land.Jul 24 2018, 4:27 PM
This revision was automatically updated to reflect the committed changes.