This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Report unsupported maximum_operations_per_instruction values
ClosedPublic

Authored by jhenderson on Feb 19 2020, 1:17 AM.

Details

Summary

This patch adds a check which reports an unsupported value of the maximum_operations_per_instruction field in a debug line table header. This is reported once per line table, at most, and only if the table would otherwise need to use it (i.e. never for tables with version 3 or less, or for tables which don't use DW_LNS_const_add_pc or special opcodes). Unsupported values are currently any apart from 1.

See also D43470, which takes a similar approach for bad line_range values (i.e. 0). I may refactor the pair of them to avoid the code duplication.

Depends on D75188.

Diff Detail

Event Timeline

jhenderson created this revision.Feb 19 2020, 1:17 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 19 2020, 1:17 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
jhenderson planned changes to this revision.Feb 19 2020, 6:04 AM

There are a couple of issues in this change, and I also want to refactor it and D43470 to share some code.

probinson added inline comments.Feb 20 2020, 12:51 PM
llvm/unittests/DebugInfo/DWARF/DWARFDebugLineTest.cpp
9

Should not have moved this; it's not the header for this module.

jhenderson marked an inline comment as done.Feb 21 2020, 12:55 AM
jhenderson added inline comments.
llvm/unittests/DebugInfo/DWARF/DWARFDebugLineTest.cpp
9

Weird. I don't know how that happened. I certainly wouldn't have deliberately moved it.

jhenderson edited the summary of this revision. (Show Details)
jhenderson added a reviewer: labath.

Rewrite to allow for other similar checks to be added in subsequent changes. See D43470 and another patch TBD. See the full patch series for why the test unit test is written the way it is (the other two patches reuse the fixture).

ikudrin added inline comments.Feb 27 2020, 3:56 AM
llvm/unittests/DebugInfo/DWARF/DWARFDebugLineTest.cpp
766

clang-9 shows a warning here:

DWARFDebugLineTest.cpp:752:8: warning: '(anonymous namespace)::AdjustAddressFixtureBase' has virtual functions but non-virtual destructor [-Wnon-virtual-dtor]
942

Yet another warning:

DWARFDebugLineTest.cpp:928:8: warning: 'SetUp' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]

The similar warnings are also shown for SetUp methods in the dependent patches.

jhenderson marked an inline comment as done.Feb 28 2020, 4:48 AM
jhenderson added inline comments.
llvm/unittests/DebugInfo/DWARF/DWARFDebugLineTest.cpp
942

Does this SetUp warning also apply for the DebugLineParameterisedFixture or DebugLineUnsupportedVersionFixture classes? They aren't new, but are missing overrides on their SetUp functions.

ikudrin added inline comments.Feb 28 2020, 5:18 AM
llvm/unittests/DebugInfo/DWARF/DWARFDebugLineTest.cpp
942

Nope. The warning appears if some methods in a class are missing override.

jhenderson updated this revision to Diff 247603.Mar 2 2020, 4:40 AM
jhenderson marked 4 inline comments as done.

Rebase and move some of the parameters to the ParsingState class to reduce the number of arguments required in the functions. Also fix warnings mentioned by @ikudrin.

DWARFDebugLine.h has a pre-merge clang-format note, did you miss that?

DWARFDebugLine.h has a pre-merge clang-format note, did you miss that?

Oops, my bad (a result of a bad rebase/merge that was). I'll fix it.

jhenderson updated this revision to Diff 248136.Mar 4 2020, 3:13 AM

Fix formatting.

probinson added inline comments.Mar 4 2020, 9:17 AM
llvm/include/llvm/DebugInfo/DWARF/DWARFDebugLine.h
374 ↗(On Diff #248136)

As a future API simplification, think about using dwarf::LNStandardName() to compute the names as needed, instead of passing around strings. LNStandardName() would need an opcode_base parameter to know which ones are special for a particular line-number program, but it's used in only one place that I can find, so that should be an easy update.
I know there's the weird case of DW_LNS_const_add_pc where you're basing the advance on 255 but want to use the real opcode for reporting; but the weird cases are why we pay you the big bucks.

llvm/unittests/DebugInfo/DWARF/DWARFDebugLineTest.cpp
9

Did it move again? If you ran clang-format, I wonder if there's a bug in it (it might think it's moving the "module's" header to the top, but have incorrect module-header detection).

jhenderson updated this revision to Diff 248417.Mar 5 2020, 3:12 AM
jhenderson marked 2 inline comments as done.

Fix formatting again. I blame Visual Studio...!

jhenderson marked an inline comment as done.Mar 5 2020, 5:52 AM
jhenderson added inline comments.
llvm/include/llvm/DebugInfo/DWARF/DWARFDebugLine.h
374 ↗(On Diff #248136)

I had a play around with this, and LNStandardName isnt't suitable for passing in opcode_base with directly, as it needs to share the interface with the equivalent functions for other DWARF enum types. I can workaround this with a little extra logic though, I think.

llvm/unittests/DebugInfo/DWARF/DWARFDebugLineTest.cpp
9

Weird...

jhenderson updated this revision to Diff 248465.Mar 5 2020, 6:36 AM

Redo name handling to remove the need for specifying it explicitly.

Thanks for simplifying the API. One more bit of code tidying and I think I will be happy.

llvm/lib/DebugInfo/DWARF/DWARFDebugLine.cpp
573

Sink this under the if as you don't need the name unless you're reporting the warning.

587

After sinking the getOpcodeName call, you have a block under the if instead of just a single statement, in which case you might as well move ReportAdvanceAddrProblem = false into that block as well.
These moves help distinguish the error-reporting stuff from the functional stuff as well.

jhenderson marked 2 inline comments as done.Mar 6 2020, 2:48 AM
jhenderson added inline comments.
llvm/lib/DebugInfo/DWARF/DWARFDebugLine.cpp
573

It's used in the second error added in D75189, so I don't think sinking it inside the if makes much sense.

587

Same response as above. Given the additional error message in D75189, I can't put it inside the if.

jhenderson updated this revision to Diff 248683.Mar 6 2020, 2:54 AM

Fix formatting.

This revision is now accepted and ready to land.Mar 6 2020, 1:12 PM
MaskRay accepted this revision.Mar 6 2020, 2:58 PM
MaskRay added inline comments.
llvm/lib/DebugInfo/DWARF/DWARFDebugLine.cpp
507

struct can be omitted (and conventional in C++).

llvm/unittests/DebugInfo/DWARF/DWARFDebugLineTest.cpp
942

public can be omitted for struct.

jhenderson updated this revision to Diff 249055.Mar 9 2020, 4:07 AM
jhenderson marked an inline comment as done.

Get rid of some unnecessary public usage.

This revision was automatically updated to reflect the committed changes.
jhenderson added inline comments.Mar 9 2020, 7:36 AM
llvm/lib/DebugInfo/DWARF/DWARFDebugLine.cpp
507

I took a look at this, but LineTable is both a member name and struct name here. We'd have to explicitly qualify the type name to be DWARFDebugLine::LineTable. There are several similar maybe unnecessary struct specifiers in the header too, but these are all because various members have the same name as their type. I'd recommend leaving this until the variable case changes are made in this code, after which there should be no ambiguity.