[Lldb-commits] [PATCH] D61244: Re-enable gmodules tests on Linux
Pavel Labath via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Tue Apr 30 06:08:08 PDT 2019
labath added a comment.
In D61244#1482196 <https://reviews.llvm.org/D61244#1482196>, @teemperor wrote:
> In D61244#1482146 <https://reviews.llvm.org/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 <https://reviews.llvm.org/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.
CHANGES SINCE LAST ACTION
More information about the lldb-commits