On 21/02/2019 19:48, Ted Woodward wrote:
-----Original Message-----
From: lldb-dev <lldb-dev-boun...@lists.llvm.org> On Behalf Of Pavel Labath
via lldb-dev
Sent: Thursday, February 21, 2019 8:35 AM
To: Davide Italiano <dccitali...@gmail.com>
Cc: LLDB <lldb-dev@lists.llvm.org>
Subject: [EXT] Re: [lldb-dev] [RFC]The future of pexpect
On 21/02/2019 00:03, Davide Italiano wrote:
I found out that there are tests that effectively require
interactivity. Some of the lldb-mi ones are an example.
A common use-case is that of sending SIGTERM in a loop to make sure
`lldb-mi` doesn't crash and handle the signal correctly.
This functionality is really hard to replicate in lit_as is_.
Any ideas on how we could handle this case?
How hard is it to import a new version of pexpect which supports python3 and
stuff?
I'm not sure how the situation is on darwin, but I'd expect (:P) that most linux
systems either already have it installed, or have an easy way to do so. So we
may not even be able to get away with just using the system one and skipping
tests when it's not present.
BTW, for lldb-mi I would actually argue that it should *not* use pexpect :D.
Interactivity is one thing, and I'm very much in favour of keeping that ability,
but pexpect is not a prerequisite for that. For me, the main advantage of
pexpect is that it emulates a real terminal. However, lldb-mi does not need
that stuff. It doesn't have any command line editing capabilities or similar.
It's
expecting to communicate with an IDE over a pipe, and that's it.
Given that, it should be fairly easy to rewrite the lldb-mi tests to work on top
of the standard python "subprocess" library. While we're doing that, we might
actually fix some of the issues that have been bugging everyone in the lldb-mi
tests. At least for me, the most annoying thing was that when lldb-mi fails to
produce the expected output, the test does not fail immediately, but instead
the implementation of self.expect("^whatever") waits until the timeout
expires, optimistically hoping that it will find some output that match the
pattern.
If we change this to something like self.expect_reply("^whatever"), and make
the "expect_reply" function smart enough to know that lldb-mi's response
should come as a single line, and if the first line doesn't match, it should
abort,
this problem would be fixed. While we're at it, we could also tune the failure
message so that it's more helpful than the current implementation. Plus, that
would solve the issue of not being able to run lldb-mi tests on windows.
This would be OK, I think, as long as "expect_reply" has the option to do a
partial match,
or a regex match. Some of the lldb-mi tests only look for certain parts of the
reply.
Yes, except from the difference in treating "messages" independently,
the function could/should have the same matching capabilities as the
current one.
I do see an opportunity to improve this to do some kind of
structure-aware matching (expect_reply("library-loaded",
target_name="foo.so", loaded_addr=0x47000)). IMO, that would make these
tests superior even to the current lit tests, but I'm not an lldb-mi
developer, so I'll probably stop short of doing that. :)
Also, until Python2 is declared dead and not supported at all by lldb, we
should be able
to run this under 2 or 3.
Yes, of course.
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
