This is an archive of the discontinued LLVM Phabricator instance.

Make debug info specification use categories system
ClosedPublic

Authored by zturner on Dec 10 2015, 11:41 AM.

Details

Summary

I'm not sure if I did this right, but the end result of this CL is removal of the -N command line option, and making people go through the categories system instead.

Diff Detail

Repository
rL LLVM

Event Timeline

zturner updated this revision to Diff 42451.Dec 10 2015, 11:41 AM
zturner updated this revision to Diff 42452.
zturner retitled this revision from to Make debug info specification use categories system.
zturner updated this object.
zturner added reviewers: labath, tberghammer.
zturner added a subscriber: lldb-commits.

Actually remove the -N command line option as well.

labath requested changes to this revision.Dec 11 2015, 2:32 AM
labath edited edge metadata.

The interaction between the add_test_categories and the "magic test multiplier" is causing problems, which is evident in the fact how you needed to add the @skip decorator to make it work.

It sounds like we need to decide what will be the "correct" interaction of the "test multiplier" and tests manually marked with a specific debug info.

I think the most sensible behavior would be to treat a manual debuginfo mark as a signal that you don't want your test to be auto-multiplied, the test multiplier could then check whether the test is already marked with one of the debuginfo annotations, and if it is, then avoid touching it.

What do you think?

packages/Python/lldbsuite/test/functionalities/unwind/standard/TestStandardUnwind.py
120 ↗(On Diff #42452)

You need [] around the "dwarf". Otherwise, you will get errors here, when the skipIf below does not actually skip.

packages/Python/lldbsuite/test/lang/cpp/limit-debug-info/TestWithLimitDebugInfo.py
10 ↗(On Diff #42452)

It should not be necessary to annotate and skip at the same time.

packages/Python/lldbsuite/test/lldbtest.py
2226 ↗(On Diff #42452)

Here, we would then also check getCategoriesForTest(attrvalue) for presence of debug info markers. It looks like you will need to move that function from test_result.py to somewhere else though...

2230 ↗(On Diff #42452)

might as well use getDarwinOSTriples() here

2233 ↗(On Diff #42452)

This annotation will overwrite any previous category annotations that the user has previously added. I wasn't sure whether we wanted this behavior when I was writing the decorator, but now that we have these automatic categorizations, it definitely sounds like a bad idea. add_test_categories should really "add" categories to the test.

Since this is quite orthogonal to your patch, I'll whip up a separate patch to do that.

This revision now requires changes to proceed.Dec 11 2015, 2:32 AM
labath added inline comments.Dec 11 2015, 8:03 AM
packages/Python/lldbsuite/test/lldbtest.py
2226 ↗(On Diff #42452)

Actually, getCategoriesForTest(attrvalue) will not work here, as the test is not running and the class is not constructed yet. After D15451 you should be able to do something like this here:

categories = getattr(attrvalue, "categories", [])
if not set(categories).intersection(["dwarf", "dsym", "dwo"]):
  categories = ["dwarf", "dsym", "dwo"]
dont_do_dsym_test = any(platform in target_platform for platform in ["linux", "freebsd", "windows"]) or ("dsym" not in categories)
dont_do_dwo_test = any(platform in target_platform for platform in getDarwinOSTriples()) or ("dwo" not in categories)
dont_do_dwarf_test = "dwarf" not in categories

This way, if the test is categorized with a debug info marker, we use that info to choose which tests to generate. If the test is not categorized, we just use the default platform rules.

Zach, Tamas, how does that sound?

2233 ↗(On Diff #42452)

I have this up it D15451.

The interaction between the add_test_categories and the "magic test multiplier" is causing problems, which is evident in the fact how you needed to add the @skip decorator to make it work.

It sounds like we need to decide what will be the "correct" interaction of the "test multiplier" and tests manually marked with a specific debug info.

I think the most sensible behavior would be to treat a manual debuginfo mark as a signal that you don't want your test to be auto-multiplied, the test multiplier could then check whether the test is already marked with one of the debuginfo annotations, and if it is, then avoid touching it.

In hindsight I wonder if I even needed to manually mark the test with a debug info. Maybe we can say that tests should *never* be manually marked with a debug info category, and only use the skip decorators. That should still work, because it will be auto-multiplied to every debug format, and then some of them will be skipped.

zturner updated this revision to Diff 42550.Dec 11 2015, 11:31 AM
zturner edited edge metadata.

Updated with comments from previous review. Also change the multiplication logic to use a loop instead of writing each one separately.

tberghammer added inline comments.Dec 14 2015, 3:17 AM
packages/Python/lldbsuite/test/lang/cpp/limit-debug-info/TestWithLimitDebugInfo.py
9 ↗(On Diff #42550)

Considering your change in lldbtest.py:2227 I think you should annotate the function with add_test_categories(["dwarf"]) instead

packages/Python/lldbsuite/test/lldbtest.py
2227–2228 ↗(On Diff #42550)

I think this won't work if the list of debug info formats are specified on class level instead of at function level.

labath accepted this revision.Dec 14 2015, 5:36 AM
labath edited edge metadata.

In hindsight I wonder if I even needed to manually mark the test with a debug info. Maybe we can say that tests should *never* be manually marked with a debug info category, and only use the skip decorators. That should still work, because it will be auto-multiplied to every debug format, and then some of them will be skipped.

I quite like that. @dwarf_test essentially means "skip if debug info is not dwarf", so why not state that explicitly... I'm not going to ask you to rewrite it again, but if you feel like it, then by all means go for it.

packages/Python/lldbsuite/test/lldbtest.py
2227–2228 ↗(On Diff #42550)

That's true, but given that it's difficult to access the class annotations from this context, I'm fine with living with this "defect", at least for now. Although, it sounds like that if we go with the option Zachary proposes, this problem would go away...

This revision is now accepted and ready to land.Dec 14 2015, 5:36 AM
This revision was automatically updated to reflect the committed changes.