This is an archive of the discontinued LLVM Phabricator instance.

Re-enable gmodules tests on Linux
Changes PlannedPublic

Authored by teemperor on Apr 28 2019, 12:21 PM.

Details

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.

Diff Detail

Event Timeline

teemperor created this revision.Apr 28 2019, 12:21 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 28 2019, 12:21 PM
teemperor edited the summary of this revision. (Show Details)Apr 28 2019, 12:21 PM
davide accepted this revision.Apr 28 2019, 4:13 PM
davide added a subscriber: davide.

LGTM

This revision is now accepted and ready to land.Apr 28 2019, 4:13 PM

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.

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 updated this revision to Diff 197074.Apr 29 2019, 3:08 AM
  • Add 'linux' to the list of platforms supporting gmodules.
teemperor planned changes to this revision.Apr 29 2019, 1:50 PM
teemperor added a reviewer: aprantl.

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.

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.

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.