This test is flaky on the windows->android bot. Change assertTrue to
assertEqual in the hope better error messages will direct us to the
problem.
llvm-svn: 294737
Summary:
The server was no longer sending the thread PCs the way the client
expected them.
I changed the server to send them back as a threadstop info field,
similar to the Apple version of the server.
I also changed the client to look for them there, before querying the
server.
I added a test to ensure the server doesn't stop sending them.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D28880
Author: Jason Majors
llvm-svn: 292611
We are going to turn off buffer overflow introduced by gcc by turning off
FORTIFY_SOURCE.
Differential revision: https://reviews.llvm.org/D28666
llvm-svn: 291949
Summary:
Some of the mi commands implemented in lldb-mi are incomplete/not confirming to the spec.
- `gdb-show` and `gdb-set` doesn't support getting/setting `disassembly-flavor`
- `environment-cd` should also change the working directory for inferior
- debugger CLI output should be printed as console-stream-output record, rather than being dumped directly
to stdout
- `target-select` should provide inner error message in mi response
Related bug report:
- https://llvm.org/bugs/show_bug.cgi?id=28026
- https://llvm.org/bugs/show_bug.cgi?id=28718
- https://llvm.org/bugs/show_bug.cgi?id=30265
Reviewers: ki.stfu, abidh
Subscribers: abidh, ki.stfu, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D24711
llvm-svn: 291104
r290874 enabled the s390x test, which caused the rest of the tests to start
misbehaving. This is because this test switches the selected platform and the
change persists.
This fixes it by explicitly resetting the platform in a similar way to the gcore
tests do. Potentially we should consider re-setting the platform globally
between each test run to better protect tests from each other.
llvm-svn: 290890
Summary:
This patch changes and simplifies the way notes are read from Linux Elf cores.
The current implementation copies the bytes from the notes directly over the lldb structure for 64 bit cores and reads field by field for 32 bit cores. Reading the bytes directly only works if the endianess of the core dump and the platform that lldb are running on matches. The case statements for s390x and x86_64 would would only work on big endian systems and little endian systems respectively. That meant that x86_64 generally worked but s390x didn't unless you were on s390x or another big endian platform.
This patch just reads field by field on all platform and updates the field by field version to allow for those fields which are word size instead of fixed size. It should also slightly simplify adding support for a new Linux platform.
This patch also re-enables the s390x test case in TestLinuxCore.py on all non-s390x platforms as it now passes.
Reviewers: uweigand, clayborg
Differential Revision: https://reviews.llvm.org/D27571
llvm-svn: 290874
We're seeing some very occasional failures in these tests where the
mini-driver dies with a SIGPIPE. We don't use SIGPIPE for anything, and
the main lldb driver program already ignores SIGPIPE, so ignoring it in
the mini-driver is a good way to remove these spurious failures.
<rdar://problem/29740488>
llvm-svn: 290216
Fixed by additional completed plans detection, and applying them on breakpoint condition fail.
Thread::GetStopInfo reworked. New test added.
Review https://reviews.llvm.org/D26497
Many thanks to Jim
llvm-svn: 290168
We don't parse ObjC v1 types from the runtime metadata like we do for ObjC v2, but doing so by creating empty types was ruining the i386 v1 debugging experience.
<rdar://problem/24093343>
llvm-svn: 289233
This test links against liblldb, so it can only run when the target arch is the
same arch as liblldb. We already have a decorator for that, so apply it.
While I'm in there, also mark the test as debug-info independent.
llvm-svn: 289199
I found the race condition in:
ScriptInterpreter *CommandInterpreter::GetScriptInterpreter(bool can_create);
More than one "ScriptInterpreter *" was being returned due to the race which caused any clients with the first one to now be pointing to freed memory and we would quickly crash.
Added a test to catch this so we don't regress.
<rdar://problem/28356584>
llvm-svn: 289169
to not be set by Process::WillPublicStop() so the driver won't get
access to them. The fix is straightforward, moving the call to
WillPublicStop above the early return for the interrupt case. (the
interrupt case does an early return because the rest of the function
is concerned with running stop hooks etc and those are not applicable
when we've interrupted the process).
Also added a test case for it. The test case is a little complicated
because I needed to drive lldb asynchronously to give the program
a chance to get up and running before I interrupt it. Running to
a breakpoint was not sufficient to catch this bug.
<rdar://problem/22693778>
llvm-svn: 289026
We have a longstanding issue where the expression parser does not handle wide CFStrings (e.g., @"凸凹") correctly, producing the useless error message
Internal error [IRForTarget]: An Objective-C constant string's string initializer is not an array
error: warning: expression result unused
error: The expression could not be prepared to run in the target
This is just a side effect of the fact that we don't handle wide string constants when converting these to CFStringCreateWithBytes. That function takes the string's encoding as an argument, so I made it work and added a testcase.
https://reviews.llvm.org/D27291
<rdar://problem/13190557>
llvm-svn: 288386
The current implementation of the decorator does not skip if the android target
arch is the same as host arch (as in both cases the platform comes out as linux).
Nonetheless android x86_64 binaries are not compatible with linux ones.
Technically this should be "skip if target is android and host is *not* android",
but currently nobody runs lldb test suite on an android host, so we don't even
have a way of specifying that the host is android.
llvm-svn: 288027
The line numbers come out slightly differently when the test is run with gcc-4.9
as a compiler. The test probably should not depend on that, but that is a
different story.
llvm-svn: 287893
This test passes consistently on linux, so I am removing the overall XFAIL. If it
fails on your configuration, please put a targeted xfail instead (i'll add them
my self if I get any breakage emails).
llvm-svn: 287881
Summary:
This patch changes the way ProcessElfCore.cpp handles signal information.
The patch changes ProcessElfCore.cpp to use the signal from si_signo in SIGINFO notes in preference to the value of cursig in PRSTATUS notes. The value from SIGINFO seems to be more thread specific. The value from PRSTATUS is usually the same for all threads even if only one thread received a signal.
If it cannot find any SIGINFO blocks it reverts to the old behaviour and uses the value from cursig in PRSTATUS. If after that no thread appears to have been stopped it forces the status of the first thread to be SIGSTOP to prevent lldb hanging waiting for any thread from the core file to change state.
The order is:
- If one or more threads have a non-zero si_signo in SIGINFO that will be used.
- If no threads had a SIGINFO block with a non-zero si_signo set all threads signals to the value in cursig in their PRSTATUS notes.
- If no thread has a signal set to a non-zero value set the signal for only the first thread to SIGSTOP.
This resolves two issues. The first was identified in bug 26322, the second became apparent while investigating this problem and looking at the signal values reported for each thread via “thread list”.
Firstly lldb is able to load core dumps generated by gcore where each thread has a SIGINFO note containing a signal number but cursig in the PRSTATUS block for each thread is 0.
Secondly if a SIGINFO note was found the “thread list” command will no longer show the same signal number for all threads. At the moment if a process crashes, for example with SIGILL, all threads will show “stop reason = signal SIGILL”. With this patch only the thread that executed the illegal instruction shows that stop reason. The other threads show “stop reason = signal 0”.
Reviewers: jingham, clayborg
Subscribers: sas, labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D26676
llvm-svn: 287858
Pavel Labath