| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
I have previously enabled this test for this configuration. However, it turns
out it only passes for gcc-4.9.
llvm-svn: 291563
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: labath, clayborg
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
Differential Revision: https://reviews.llvm.org/D27088
llvm-svn: 291554
|
|
|
|
| |
llvm-svn: 291553
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: labath, clayborg
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
Differential Revision: https://reviews.llvm.org/D27088
llvm-svn: 291549
|
|
|
|
| |
llvm-svn: 291350
|
|
|
|
|
|
| |
The clang bug is fixed now. This reverts commit r291100.
llvm-svn: 291225
|
|
|
|
|
|
|
| |
My earlier commit today seem to cause a failure on a darwin buildbot.
I am skipping the test while I investigate the failure.
llvm-svn: 291118
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
the test fails due to a bug in ToT clang
llvm-svn: 291100
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
TestNoreturnUnwind fails on arm/aarch32 linux targets.
Bug is already described for x86_64 android targets in llvm.org/pr31192.
llvm-svn: 290821
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 290197
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 289695
|
|
|
|
|
|
|
| |
The test passes on linux. The i386 case is already handled by
skipIfHostIncompatibleWithRemote.
llvm-svn: 289427
|
|
|
|
|
|
|
|
|
|
| |
empty objective C types from the runtime.
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
|
|
|
|
|
|
| |
that TestMultipleDebuggers.py has.
llvm-svn: 289223
|
|
|
|
| |
llvm-svn: 289222
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg, labath, zturner
Subscribers: jaydeep, bhushan, slthakur, lldb-commits
Differential Revision: https://reviews.llvm.org/D27085
llvm-svn: 289210
|
|
|
|
|
|
|
|
|
|
|
|
| |
qprocessInfo packet.
Reviewers: jaydeep, bhushan, clayborg
Subscribers: slthakur, lldb-commits
Differential Revision: https://reviews.llvm.org/D26542
llvm-svn: 289209
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
crashing LLDB.
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
|
|
|
|
| |
llvm-svn: 289155
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
r288535.
llvm-svn: 288542
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D27282
llvm-svn: 288282
|
|
|
|
| |
llvm-svn: 288032
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Test passes consistently, at least on linux.
llvm-svn: 287887
|
|
|
|
|
|
| |
Passing consistently now.
llvm-svn: 287885
|
|
|
|
|
|
| |
The test has been passing for a while now.
llvm-svn: 287884
|
|
|
|
|
|
| |
It consistently passes for linux-clang-i386, and linux-gcc-x86_64.
llvm-svn: 287883
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Correct 0 byte core files uploaded by arc.
llvm-svn: 287861
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
32/64 bit elf core files
Summary:
The floating-point and SSE registers could be present in the elf-core
file in the note NT_FPREGSET for 64 bit ones, and in the note
NT_PRXFPREG for 32 bit ones.
The entire note is a binary blob matching the layout of the x87 save
area that gets generated by the FXSAVE instruction (see Intel developers
manual for more information).
This CL mainly modifies the RegisterRead function in
RegisterContextPOSIXCore_x86_64 for it to return the correct data both
for GPR and FPR/SSE registers, and return false (meaning "this register
is not available") for other registers.
I added a test to TestElfCore.py that tests reading FPR/SSE registers
both from a 32 and 64 bit elf-core file and I have inluded the source
which I used to generate the core files.
I tried to also add support for the AVX registers, because this info could
also be present in the elf-core file (note NT_X86_XSTATE - that is the result of
the newer XSAVE instruction). Parsing the contents from the file is
easy. The problem is that the ymm registers are split into two halves
and they are in different places in the note. For making this work one
would either make a "hacky" approach, because there won't be
any other way with the current state of the register contexts - they
assume that "this register is of size N and at offset M" and
don't have the notion of discontinuos registers.
Reviewers: labath
Subscribers: emaste, lldb-commits
Differential Revision: https://reviews.llvm.org/D26300
llvm-svn: 287506
|
|
|
|
|
|
| |
Also document that it handles same, and add some tests.
llvm-svn: 287386
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.
Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.
Differential Revision: https://reviews.llvm.org/D26698
llvm-svn: 287152
|
|
|
|
|
|
|
|
| |
On Windows, where we use Python 3 for testing, we have to be more explicit about converting between binary and string representations. I believe this should still work for Python 2, but I don't have a convenient way to try it out.
Differential Revision: https://reviews.llvm.org/D26643
llvm-svn: 286909
|
|
|
|
|
|
|
|
|
|
| |
With this patch LLDB_VERSION_STRING replaces "lldb version x.x.x" if it is set. This allows builds to not display the open source version numbers if the people making the distribution overrides the LLDB_VERSION_STRING.
Since LLDB_VERSION_STRING is always overridden on Darwin, this means the first line of lldb -version on Darwin is:
lldb-360.99.0 (<repo path> revision <revision>)
llvm-svn: 286899
|
|
|
|
| |
llvm-svn: 286722
|
|
|
|
| |
llvm-svn: 286581
|
|
|
|
|
|
|
|
| |
Fails with all versions of arm/aarch64 gcc available on ubuntu 16.04/14.04.
Passes with Linaro GCC version >= 4.8 but fails with >= 5.0. But There are other regressions when we use Linaro GCC.
llvm-svn: 286574
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch reworks all the @skip... lines for sanitizer libraries to be based on whether or not the compiler actually works, rather than whether or not the compiler-rt sources are present in some magically derived directory.
Reviewers: lldb-commits
Subscribers: kubabrecka, tfiala
Differential Revision: https://reviews.llvm.org/D26513
llvm-svn: 286490
|
|
|
|
| |
llvm-svn: 286476
|