Re-enable gmodules tests on Linux

[teemperor]

Summary

These tests are not failing for me on (Arch) Linux, so I would suggest that we re-enable them. See also http://llvm.org/pr36107 which is the reason we disabled them.

[davide]

LGTM

[labath]

LG, but note that this has no effect on the overall set of tests which will run as long as gmodules remains disabled in test_categories.is_supported_on_platform.

The other thing to note is that the effect of enabling gmodules extremely strongly depends on how your system is configured. (Almost) none of our test define their own modules, so the only modules that lldb might end up using are the ones from the system libraries. Which is kind of way I think our way of testing module debugging support is broken. We have enough problems with people reporting tests which only break for them because of some quirk in their system libraries without us throwing modules into the mix.

[teemperor]

In D61244#1482146, @labath wrote:

LG, but note that this has no effect on the overall set of tests which will run as long as gmodules remains disabled in test_categories.is_supported_on_platform.

Oh, true, thanks for the hint! With the current categories it seems the test always just get's marked as PASS (TM) on Linux... But luckily it actually passes even when I enable linux in the category filter.

The other thing to note is that the effect of enabling gmodules extremely strongly depends on how your system is configured. (Almost) none of our test define their own modules, so the only modules that lldb might end up using are the ones from the system libraries. Which is kind of way I think our way of testing module debugging support is broken. We have enough problems with people reporting tests which only break for them because of some quirk in their system libraries without us throwing modules into the mix.

It's true that the gmodules-templates test touches system modules. I'm fine with rewriting them to not use system modules (or disable the ones that really have to use system modules on LInux) as long as we have some gmodules coverage on Linux.

[teemperor]

• Add 'linux' to the list of platforms supporting gmodules.

[teemperor]

I looked into this a bit further and I think the best way forward is to enable gmodules on Linux but exclude all tests that rely on system modules (i.e. std or libc) as that really seems to be a messy situation. I'll update the patch accordingly.

[labath]

In D61244#1482196, @teemperor wrote:

In D61244#1482146, @labath wrote:

LG, but note that this has no effect on the overall set of tests which will run as long as gmodules remains disabled in test_categories.is_supported_on_platform.

Oh, true, thanks for the hint! With the current categories it seems the test always just get's marked as PASS (TM) on Linux... But luckily it actually passes even when I enable linux in the category filter.

Yeah, we really ought to do something about that test situation... I tried to fix that by teaching lit to consider every flavour as a separate test, but it turned out that had pretty big performance hit, so I'm currently out of ideas...

The other thing to note is that the effect of enabling gmodules extremely strongly depends on how your system is configured. (Almost) none of our test define their own modules, so the only modules that lldb might end up using are the ones from the system libraries. Which is kind of way I think our way of testing module debugging support is broken. We have enough problems with people reporting tests which only break for them because of some quirk in their system libraries without us throwing modules into the mix.

It's true that the gmodules-templates test touches system modules. I'm fine with rewriting them to not use system modules (or disable the ones that really have to use system modules on LInux) as long as we have some gmodules coverage on Linux.

The fact that they touch the system modules is not my main concern. After all, other tests also read the debug info of system libraries (*). The difference may be that module debugging is less mature, and so more likely to break unrelated stuff, but the principle is the same. The problem I have is that most of the tests don't touch *anything except* system modules. So, if you don't happen to have a system with module-capable system libraries (which most linux systems don't), the test will test absolutely nothing, yet you'll be burning cpu cycles running all these "gmodules" tests and thinking how great this module debugging stuff works.

(*) Note that we're slowly clamping down on those as well. We have already replaced a bunch of tests that verify that you can e.g. backtrace out of a random place in libc with something more deterministic.

In D61244#1483030, @teemperor wrote:

I looked into this a bit further and I think the best way forward is to enable gmodules on Linux but exclude all tests that rely on system modules (i.e. std or libc) as that really seems to be a messy situation. I'll update the patch accordingly.

Yeah, it would certainly be great to run the tests that go through the trouble of creating their own modules (thank you for that). We should have more of those.

lldb/packages/Python/lldbsuite/test/lang/cpp/gmodules-templates/TestGModules.py

 import lldbsuite.test.lldbinline as lldbinline
-from lldbsuite.test.decorators import *
 
-lldbinline.MakeInlineTest(__file__, globals(), [
-    expectedFailureAll(oslist=["linux"], bugnumber="llvm.org/pr36107",
-        debug_info="gmodules")])
+lldbinline.MakeInlineTest(__file__, globals())

lldb/packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py

 import lldb
 import os
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
 
 
 class TestWithGmodulesDebugInfo(TestBase):
 
     mydir = TestBase.compute_mydir(__file__)
 
-    @skipIf(bugnumber="llvm.org/pr36146", oslist=["linux"], archs=["i386"])
     @add_test_categories(["gmodules"])
     def test_specialized_typedef_from_pch(self):
         self.build()
 
         src_file = os.path.join(self.getSourceDir(), "main.cpp")
         src_file_spec = lldb.SBFileSpec(src_file)
         self.assertTrue(src_file_spec.IsValid(), "breakpoint file")
 

lldb/packages/Python/lldbsuite/test/test_categories.py

 def is_supported_on_platform(category, platform, compiler_path):
     if category == "dwo":
         # -gsplit-dwarf is not implemented by clang on Windows.
         return platform in ["linux", "freebsd"]
     elif category == "dsym":
         return platform in ["darwin", "macosx", "ios", "watchos", "tvos", "bridgeos"]
     elif category == "gmodules":
         # First, check to see if the platform can even support gmodules.
-        if platform not in ["freebsd", "darwin", "macosx", "ios", "watchos", "tvos", "bridgeos"]:
+        if platform not in ["freebsd", "darwin", "macosx", "ios", "watchos", "tvos", "bridgeos", "linux"]:
             return False
         return gmodules.is_compiler_clang_with_gmodules(compiler_path)
     return True
 
 
 def validate(categories, exact_match):
     """
     For each category in categories, ensure that it's a valid category (if exact_match is false,