[llvm-dev] Status of debuginfo-tests
David Blaikie via llvm-dev
llvm-dev at lists.llvm.org
Thu Sep 7 11:40:43 PDT 2017
On Thu, Sep 7, 2017 at 11:34 AM Zachary Turner <zturner at google.com> wrote:
> Even if it were under llvm, that doesn't mean it would have to be part of
> ninja check-all. Currently we have lldb/test and lldb/unittests, what
> about a third lldb/dbgtests? Then you could run it as ninja check-dbgtest.
Having them in lldb seems like an interesting question - not sure what the
value is in having them in a separate repo compared to having them in the
LLDB project. (I mean, long term, I think LLDB testing should probably have
fewer of these end-to-end tests (ideally few tests that actually run a
compiler/execute a resulting program (avoiding that so the tests are more
portable, reliable, etc)) - but it's reasonable to have some & probably OK
that they live in the LLDB repo (for LLVM these sort of tests live
separately in the test-suite repo)
Maybe because it makes the tests more likely to be run, more reliable (so
they don't fail due to LLDB changes - makes it easier for Clang/llvm
developers to act on regressions, etc)
> Although now that I think about it, we would want it to be able to invoke
> clang-cl directly, so I guess that does necessitate it *not* being under
> On Thu, Sep 7, 2017 at 11:26 AM David Blaikie <dblaikie at gmail.com> wrote:
>> It's used, but not a huge repository of things, as you can see. I think
>> I've run it once or twice, but a long time ago. It was introduced for/by
>> Apple/LLDB stuff, so it's not something I've paid much attention to.
>> It's probably not suitable as part of llvm tests directly. Those tests
>> are designed to be shorter/narrower/more focussed than full integration
>> tests (we don't execute any compiled programs under test there, for
>> Porting to lit seems probably fine/good.
>> On Thu, Sep 7, 2017 at 11:23 AM Zachary Turner <zturner at google.com>
>>> What is the status of debuginfo-tests? Is it actively supported? How
>>> do you run it? It doesn't appear to be based on lit, any particular
>>> reason? Why is it its own repo instead of being part of llvm repo?
>>> I'd like improve this to support CodeView and PDB, such that it would
>>> only run on Windows and only if a suitable debugger was found (probably
>>> how LLDB supports a Python based model, so my thoughts were to have a
>>> lit-based runner that scans for .js files that contain a test script
>>> alongside some source, then build the program, run it in WinDbg with some
>>> script that does various things, and exits the debugger, moving on to the
>>> next test.
>>> Anything I should be aware of / careful of when messing around in here?
>>> And any reason it can't be moved to llvm/tests and ported to lit?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev