[Lldb-commits] [PATCH] D24591: [LIT] First pass of LLDB LIT support

Zachary Turner via lldb-commits lldb-commits at lists.llvm.org
Wed Sep 14 16:00:57 PDT 2016


On Wed, Sep 14, 2016 at 3:51 PM Sean Callanan <scallanan at apple.com> wrote:

> How different is that really from
>
> (lldb) script lldb.frame.FindVariable("argc").GetValue()
> '1'
> (lldb) script lldb.process.GetNumThreads()
> 1
> (lldb) script lldb.process.GetThreadAtIndex(0).GetThreadID()
> 3514809
>
> ?  If it's developer-only, then this is even fairly well-documented using
> e.g. "script dir(lldb.process)"
>

Admittedly I hadn't thought of doing that.  That said I can think of a
couple of differences:

1. Writing it using script commands means you have to be familiar with the
python api, somewhat raising the barrier to entry for writing new tests.

2. It depends on proper behavior of the script command, which means that if
the script command itself is broken, every single test will be broken.

3. It means that building the lldb python module is required to run tests.
Wouldn't it be awesome if there was a way to run tests even with
LLDB_DISABLE_PYTHON=1?  Then script could just be a "feature" (as in, you
could limit tests which use the script command to tests whose purpose is
explicitly to test where the scripting system works, and for those you
could just add "REQUIRES: python" at the top of the lit file.  And I
imagine that not invoking python during the running of the test suite would
drastically speed up its execution.

4. You can test a LOT more things when you are able to use an api that
doesn't have to be stable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20160914/f7a8c5e8/attachment.html>


More information about the lldb-commits mailing list