Re: [lldb-dev] [RFC]The future of pexpect

[Pavel Labath via lldb-dev]

On 21/02/2019 19:48, Ted Woodward wrote:




-Original Message-
From: lldb-dev  On Behalf Of Pavel Labath
via lldb-dev
Sent: Thursday, February 21, 2019 8:35 AM
To: Davide Italiano 
Cc: LLDB 
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

[lldb-dev] [Bug 40827] New: lldb crashes on a file compiled with clang-3.8 at -O3

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=40827

Bug ID: 40827
   Summary: lldb crashes on a file compiled with clang-3.8 at -O3
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: qrzh...@gatech.edu
CC: llvm-b...@lists.llvm.org

It affects the latest lldb trunk version.
It only happens with clang-3.8 at -O3. 4.0 and later versions work fine.

$ lldb-trunk -v
lldb version 9.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk revision
354654)
  clang revision 354654
  llvm revision 354654

$ cat abc.c
char a;
int main() {
  int i;
  int b[] = {7, 7, 7};
  a = b[2];
  i = 0;
  for (; i < 5; i++)
;
  optimize_me_not();
}


$ cat outer.c
optimize_me_not() {}


$ cat cmds
b 9
r
p i
kill
q



$ clang-3.8 -O3 -g outer.c abc.c

$ lldb-trunk -s cmds -b a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) command source -s 0 'cmds'
Executing commands in '/home/absozero/projects/LLDB-testing/reduce/cmds'.
(lldb) b 9
Breakpoint 1: where = a.out`main + 10 at abc.c:9:3, address =
0x004004aa
(lldb) r
a.out was compiled with optimization - stepping may behave oddly; variables may
not be available.
 #0 0x5573e13b3d4a (lldb-trunk+0x25d4a)
 #1 0x5573e13b2074 (lldb-trunk+0x24074)
 #2 0x5573e13b21b2 (lldb-trunk+0x241b2)
 #3 0x7f89a0687890 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
 #4 0x7f8998b78c40 (/lib/x86_64-linux-gnu/libc.so.6+0x18ec40)
 #5 0x7f899a6a6641 lldb_private::DataBufferHeap::CopyData(void const*,
unsigned long)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xd62641)
 #6 0x7f899a4e94d7 lldb_private::DWARFExpression::CopyOpcodeData(unsigned
long, unsigned long, unsigned char)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xba54d7)
 #7 0x7f899a9b8674
SymbolFileDWARF::ParseVariableDIE(lldb_private::SymbolContext const&, DWARFDIE
const&, unsigned long)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0x1074674)
 #8 0x7f899a9b93c4
SymbolFileDWARF::ParseVariables(lldb_private::SymbolContext const&, DWARFDIE
const&, unsigned long, bool, bool, lldb_private::VariableList*)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0x10753c4)
 #9 0x7f899a9ba150
SymbolFileDWARF::ParseVariablesForContext(lldb_private::SymbolContext const&)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0x1076150)
#10 0x7f899a5a8e82
lldb_private::SymbolVendor::ParseVariablesForContext(lldb_private::SymbolContext
const&) (/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xc64e82)
#11 0x7f899a56312e lldb_private::Block::GetBlockVariableList(bool)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xc1f12e)
#12 0x7f899a450b14
lldb_private::FormatEntity::Format(lldb_private::FormatEntity::Entry const&,
lldb_private::Stream&, lldb_private::SymbolContext const*,
lldb_private::ExecutionContext const*, lldb_private::Address const*,
lldb_private::ValueObject*, bool, bool)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xb0cb14)
#13 0x7f899a4500b1
lldb_private::FormatEntity::Format(lldb_private::FormatEntity::Entry const&,
lldb_private::Stream&, lldb_private::SymbolContext const*,
lldb_private::ExecutionContext const*, lldb_private::Address const*,
lldb_private::ValueObject*, bool, bool)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xb0c0b1)
#14 0x7f899a4500b1
lldb_private::FormatEntity::Format(lldb_private::FormatEntity::Entry const&,
lldb_private::Stream&, lldb_private::SymbolContext const*,
lldb_private::ExecutionContext const*, lldb_private::Address const*,
lldb_private::ValueObject*, bool, bool)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xb0c0b1)
#15 0x7f899a450167
lldb_private::FormatEntity::Format(lldb_private::FormatEntity::Entry const&,
lldb_private::Stream&, lldb_private::SymbolContext const*,
lldb_private::ExecutionContext const*, lldb_private::Address const*,
lldb_private::ValueObject*, bool, bool)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xb0c167)
#16 0x7f899a626288
lldb_private::StackFrame::DumpUsingSettingsFormat(lldb_private::Stream*, bool,
char const*)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xce2288)
#17 0x7f899a6265b0
lldb_private::StackFrame::GetStatus(lldb_private::Stream&, bool, bool, bool,
char const*)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xce25b0)
#18 0x7f899a62d25a
lldb_private::StackFrameList::GetStatus(lldb_private::Stream&, unsigned int,
unsigned int, bool, unsigned int, bool, char const*)
(/home/absozero/trunk/root-clang/bin/../lib/liblldb.so.9svn+0xce925a)
#19 0x7f899a65a0e0 lldb_private::Thread::GetStatus(lldb_private::Stream&,
unsigned int, unsigned int, u