This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Don't error for zero-length arange entries
ClosedPublic

Authored by jhenderson on Aug 5 2020, 7:44 AM.

Details

Summary

Although the DWARF specification states that .debug_aranges entries can't have length zero, these can occur in the wild. There's no particular reason to enforce this part of the spec, since functionally they have no impact. The patch removes the error and introduces a new warning for premature terminator entries, which does not stop parsing.

Fixes https://bugs.llvm.org/show_bug.cgi?id=46805. See also https://reviews.llvm.org/D71932 which originally introduced the error.

Diff Detail

Event Timeline

jhenderson created this revision.Aug 5 2020, 7:44 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 5 2020, 7:44 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
jhenderson requested review of this revision.Aug 5 2020, 7:44 AM
dblaikie accepted this revision.Aug 5 2020, 10:58 AM

Any chance/worth a warning/non-fatal error?

This revision is now accepted and ready to land.Aug 5 2020, 10:58 AM
ikudrin added inline comments.Aug 6 2020, 12:00 AM
llvm/lib/DebugInfo/DWARF/DWARFDebugArangeSet.cpp
139–149
  • Thought 1: these two ifs can now be combined into one.
  • Thought 2: should not we report the premature termination of the list?

Any chance/worth a warning/non-fatal error?

I'd prefer not to - as noted elsewhere, our downstream solution for gc'ed references from .debug_aranges was to patch (-1, 0) for the .debug_aranges, so we have plenty of older objects with length 0 entries. At some point in the future these will start disappearing, now that we've moved to the new LLD tombstoning behaviour, but it would be nice to have a grace period, if that's okay?

llvm/lib/DebugInfo/DWARF/DWARFDebugArangeSet.cpp
139–149

Yeah, I wasn't sure about premature list termination. I think I'll add a warning/non-fatal error of some kind, and keep dumping - the header's length field means we know that it should be possible to ignore the terminator and continue dumping.

jhenderson updated this revision to Diff 283549.Aug 6 2020, 3:00 AM
jhenderson edited the summary of this revision. (Show Details)

I've changed the existing error to a "warning" in the event of premature terminators with this change. I could just do what was being done before and emit an error. Functionally, they end up the same, but emitting an error does not allow continued parsing of the section.

jhenderson edited the summary of this revision. (Show Details)Aug 6 2020, 3:01 AM
ikudrin added inline comments.Aug 6 2020, 3:27 AM
llvm/unittests/DebugInfo/DWARF/DWARFDebugArangeSetTest.cpp
245–247

I'd prefer this test to be divided into more basic ones. All other tests in the suite follow the idea that a unit test should check just one particular case. This helps to improve readability and maintainability. So, I'd suggest creating separate tests for cases "allow zero-length entries" and "report premature termination but continue parsing".

jhenderson updated this revision to Diff 283565.Aug 6 2020, 4:31 AM

Split unit test in two.

ikudrin accepted this revision.Aug 6 2020, 4:37 AM

LGTM, thanks!

llvm/unittests/DebugInfo/DWARF/DWARFDebugArangeSetTest.cpp
181

Did you mean Of?

jhenderson marked 2 inline comments as done.Aug 6 2020, 4:43 AM

@dblaikie - are you happy with this version?

llvm/unittests/DebugInfo/DWARF/DWARFDebugArangeSetTest.cpp
181

Nope - this test tests both length being zero and address being zero (but not both in a single entry).

ikudrin added inline comments.Aug 6 2020, 4:55 AM
llvm/unittests/DebugInfo/DWARF/DWARFDebugArangeSetTest.cpp
181

Ah! So it is still not that elementary as I hoped...

jhenderson updated this revision to Diff 283580.Aug 6 2020, 5:40 AM

Split up unit test further.

Great! Thanks.

@dblaikie - are you happy with this version?

Sounds good to me!

I'd prefer not to - as noted elsewhere, our downstream solution for gc'ed references from .debug_aranges was to patch (-1, 0) for the .debug_aranges, so we have plenty of older objects with length 0 entries. At some point in the future these will start disappearing, now that we've moved to the new LLD tombstoning behaviour, but it would be nice to have a grace period, if that's okay?

Oh, interesting - didn't realize your linker specifically truncated the range to 0 length, that totally makes sense! But now you're adopting the "new tombstoning" Semantics of -1 for the address, but leaving the length value the same as came from the input object?

I personally have no particular use for the DWARF verifier - so I'm not in a position to make strong preferences for what should or shouldn't be verified. Hopefully as a warning it might be something relatively easy to patch out in your downstream builds (not ideal, I know :/), or filter out, etc.

@dblaikie - are you happy with this version?

Sounds good to me!

Thanks, I'll go ahead and push this then.

I'd prefer not to - as noted elsewhere, our downstream solution for gc'ed references from .debug_aranges was to patch (-1, 0) for the .debug_aranges, so we have plenty of older objects with length 0 entries. At some point in the future these will start disappearing, now that we've moved to the new LLD tombstoning behaviour, but it would be nice to have a grace period, if that's okay?

Oh, interesting - didn't realize your linker specifically truncated the range to 0 length, that totally makes sense! But now you're adopting the "new tombstoning" Semantics of -1 for the address, but leaving the length value the same as came from the input object?

Yeah, we changed the length because not all our tools necessarily handled the tombstone value specifically, but a 0-length range would always be safe. We're transitioning to the new scheme however, to save us having to maintain things further.

I personally have no particular use for the DWARF verifier - so I'm not in a position to make strong preferences for what should or shouldn't be verified. Hopefully as a warning it might be something relatively easy to patch out in your downstream builds (not ideal, I know :/), or filter out, etc.

We don't officially support using the verifier either (currently). This error/warning however is emitted by llvm-dwarfdump when printing the section, which is more problematic. I don't think we'd have an issue with it being added as a verifier warning of some sort consequently, but I'm not likely to add it myself, since it is not something that is useful for us. If we ever did add support for the verification, we'd likely say it only works with objects from a certain release onwards, or something similar.

This revision was landed with ongoing or failed builds.Aug 10 2020, 4:50 AM
This revision was automatically updated to reflect the committed changes.
thakis added a subscriber: thakis.Aug 10 2020, 5:21 AM

I reverted this since it broke building obj2yaml on all bots, and the fix wasn't immediately clear to me. (We need to pass some warning handler, but I don't know which one's appropriate in obj2yaml.)

I reverted this since it broke building obj2yaml on all bots, and the fix wasn't immediately clear to me. (We need to pass some warning handler, but I don't know which one's appropriate in obj2yaml.)

Thanks. You beat me to it. Working on a fix now.

jhenderson added reviewers: Higuoxing, grimar.
jhenderson added subscribers: Higuoxing, grimar.

Fix obj2yaml code path. Either it changed since I made my change, or I just failed to build the right bits of LLVM...

@grimar/@Higuoxing, could one of you take a look at the obj2yaml changes, please?

jhenderson reopened this revision.Aug 10 2020, 6:08 AM
This revision is now accepted and ready to land.Aug 10 2020, 6:08 AM
jhenderson requested review of this revision.Aug 10 2020, 6:08 AM
Higuoxing accepted this revision.Aug 10 2020, 6:42 AM

LGTM. Thanks!

llvm/test/tools/obj2yaml/ELF/DWARF/debug-aranges.yaml
7–10

I think it might be good to put -D options together.

e.g.,

FileCheck -DLENGTH1=24 -DLENGTH2=24 -DADDRSIZE=0x04 -DVARADDR=0x1234 -DVARLEN=0x5678 %s --check-prefix=BASIC --implicit-check-not=Sections
This revision is now accepted and ready to land.Aug 10 2020, 6:42 AM

Reorder FileCheck arguments as suggested.

Higuoxing accepted this revision.Aug 10 2020, 6:51 AM
This revision was landed with ongoing or failed builds.Aug 10 2020, 6:58 AM
This revision was automatically updated to reflect the committed changes.