The following lldb unit tests fail check-lldb on ubuntu:
TestDataFormatterStdMap.py
TestDataFormatterStdVBool.py
TestDataFormatterStdVector.py
TestDataFormatterSynthVal.py
TestEvents.py
TestInitializerList.py
TestMemoryHistory.py
TestReportData.py
TestValueVarUpdate.py
These unit test failures are for non-core functionality. The intent is to
reduce the check-lldb FAILS to core functionality FAILS and then circle
back later and fix these FAILS at a later date.
llvm-svn: 222608
This was fixed by making the DWARFFormValue contain the compile unit that it needs so it can decode its form value correctly. Any form value that requires a compile unit will now assert. If any of the assertions that were added are triggered, then code that led to the extraction of the form value without properly setting the compile unit must be fixed immediately.
<rdar://problem/19035440>
llvm-svn: 222602
UnwindLLDB::AddOneMoreFrame to try the fallback unwind plan on
that same stack frame before it tries the fallback unwind plan
on the "next" or callee frame.
In RegisterContextLLDB::TryFallbackUnwindPlan, when we're
trying the fallback unwind plan to see if it is valid, make
sure we change all of the object ivars that might be used in
the process of fetching the CFA & caller's saved pc value
and restore those if we decide not to use the fallback
unwindplan.
<rdar://problem/19035079>
llvm-svn: 222601
(e.g. breakpoints, stop-hooks) before we have any targets - for instance in
your ~/.lldbinit file. These will then get copied over to any new targets
that get created. So far, you can only make stop-hooks.
Breakpoints will have to learn to move themselves from target to target for
us to get them from no-target to new-target.
We should also make a command & SB API way to prime this ur-target.
llvm-svn: 222600
Issue D5632 fixed an issue where linux would dump spurious output to tty on startup (due to a broadcast stop event). After the checkin, it was noticed on FreeBSD a unit test was now failing. On closer investigation I found the test was using the C++ API to launch an inferior while using an SBListener to monitor the public state changes. As on OSx, it was expecting to see:
eStateRunning
eStateStopped
On Linux/FreeBSD, there is an extra state change
eStateLaunching
eStateRunning
eStateStopped
I reworked the test to work for both cases and re-enabled the test of FreeBSD.
Differential Revision: http://reviews.llvm.org/D5837
llvm-svn: 222511
The default value for opt.thread_count was multiprocessing.cpu_count(),
which meant the LLDB_TEST_THREADS environment variable was never used.
It's not easy to pass the -t option to the test run when invoking it
from e.g. 'ninja check-lldb', so having the environment variable as an
option is useful.
Change the logic so that the thread count is set by the first one of:
1. The -t option to test/dosep.py
2. The LLDB_TEST_THREADS environment variable
3. The machine's CPU count from multiprocessing.cpu_count()
llvm-svn: 222501
is treated as a string instead of a FileSpec.
OptionValueFileSpec::SetValueFromCString() passes the c string to
FileSpec::SetFile(str, true /* resolve */) - and with Zachary's
changes to FileSpec we're using llvm::sys::fs::make_absolute() to
do that "resolve" action now, where we used to use realpath().
One important difference between llvm::sys::fs::make_absolute and
realpath is that when they're handed a filename (no directory),
realpath prepends the current working directory *and if the file exists*,
returns that full path. If that file doesn't exist, the caller
uses the basename only.
llvm::sys::fs::make_absolute prepends the current working directory
regardless of whether it exists or not.
I considered having FileSpec::SetFile save the initial pathname,
call FileSpec::Resolve, and then check to see if the Resolve return
path exists - and if not, go back to the original one.
But instead I just went with changing 'target modules load' to treat its
filename argument as a string instead of a FileSpec. This brings it
in line with how 'target modules list' works.
<rdar://problem/18955416>
llvm-svn: 222498
LLDB supports many different register numbering schemes, and these
are typically prefixed with an indicator that lets the user know
what numbering scheme is used. The gcc numbering scheme is
prefixed with gcc, and there are similar ones for dwarf, gdb,
and gcc_dwarf.
LLDB also contains its own internal numbering scheme, but the enum
for LLDB's numbering scheme was prefixed differently. This patch
changes the names of these enums to use the same naming scheme for
the enum values as the rest of the register kinds by removing gpr_
and fpu_ prefixes, and instead using lldb_ prefixes for all enum
values.
Differential Revision: http://reviews.llvm.org/D6351
Reviewed by: Greg Clayton
llvm-svn: 222495
Running a diff against lldb-x86-register-enums.h and the file
modified in this patch, the two enums were completely identical.
Deleting one of them to reduce code noise.
llvm-svn: 222478
This implements the skeleton of a RegisterContext for Windows.
In particular, this implements support only for x86 general purpose
registers.
After this patch, LLDB on Windows can perform basic debugging
operations in a single-threaded inferior process (breakpoint,
register inspection, frame select, unwinding, etc).
Differential Revision: http://reviews.llvm.org/D6322
Reviewed by: Greg Clayton
llvm-svn: 222474
Summary: In noack mode, these checksums are ignored by llgs, but some implementations need them still. Specify these checksums to ease integration.
Test Plan: Run the tests before and after the change and make sure nothing breaks.
Reviewers: clayborg, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6343
llvm-svn: 222441
where it is retrieving the Return Address register contents
on a target where that's a thing. If we fail to get a valid
RA, we force a switch to the fallback unwind plan. This patch
adds a sanity check for that fallback unwind plan -- it must
get a valid CFA for this frame in addition to being able to
retrieve the caller's PC -- and it correctly marks the unwind
rules as failing if the fallback unwind plan fails.
<rdar://problem/19010211>
llvm-svn: 222301
some commands that will get run if the target crashes.
Also fix the bug where the local .lldbinit file was not getting
sourced before not after the target was created from the file options on the
driver command line.
<rdar://problem/19019843>
llvm-svn: 222295
SWIG is searched under certain paths within python script. CMake can
detect SWIG with find_package(SWIG). This is used iff user checks
LLDB_ENABLE_PYTHON_SCRIPTS_SWIG_API_GENERATION. If
buildSwigWrapperClasses.py does not receive swigExecutable argument,
then the script will use its current search implementation.
llvm-svn: 222262
retrieves the personality routine addr and the
LSDA addr. Don't bother checking with the
"non-call site" unwind plan - this kind of
information is only going to come from the
call site unwind plan.
llvm-svn: 222226
deadlocking when we have the base Unwind class and the HistoryUnwind
subclass both trying to acquire the lock on the same thread to clear
their respective ivar state.
<rdar://problem/18986350>
llvm-svn: 222221
eh_frame data. These two pieces of information are used in the
process of exception handler unwinding on SysV ABI systems.
This patch reads the data from the eh_frame section
(DWARFCallFrameInfo.cpp), allows for it to be saved & read out
of a given UnwindPlan (UnwindPlan.h, UnwindPlan.cpp) - as well
as printing the information in the UnwindPlan::Dump method - and
adds methods to the FuncUnwinders object so that higher levels
can query if a given function has an LSDA / personality routine
defined.
It's only lightly tested, but seems to be working correctly as long
as your have this information in eh_frame. Does not address getting
this information from compact unwind yet on Darwin systems.
<rdar://problem/18742797>
llvm-svn: 222214
Fixed the prompt to not include non-printable characters as it was hosing up the prompt when you ran "command regex foo" and entered multi-line editing mode.
Fixed error strings to include more complete descriptions when bad regular expressions are entered.
Removed the old IOHandlerLinesUpdated function as it is no longer needed (inheriting from IOHandlerDelegateMultiline takes care of what this function used to do).
llvm-svn: 222207
The problem is that editline currently is trying to be smart when we paste things into a terminal window. It detects that input is pending and multi-line input is accepted as long as there is anything pending.
So if you open lldb and paste the text between the quotes:
"command regex carp
s/^$/help/
carp
"
We still still be stuck in the "command regex" multi-line input reader as it will have all three lines:
"s/^$/help/
carp
"
The true fix for this is something Kate Stone will soon work on:
- multi-line input readers must opt into this paste/pending input feature ("expr" will opt into it, all other commands won't)
- If we are in a multi-line input reader that requests this and stuff is pasted, then it will do what it does today
- if we start in a IOHandler that doesn't need/want pending input and text is pasted, and we transistion to a IOHandler that does want this functionality, then disable the pending input. Example text would be:
"frame variable
thread backtrace
expr
for (int i=0;i<10;++i)
(int)printf("i = %i\n", i);
frame select 0
"
When we push the expression multi-line reader we would disable the pending input because we had pending input _before_ we entered "expr".
If we did this first:
(lldb) expr
Then we pasted:
"void foo()
{
}
void bar()
{
}
"
Then we would allow the pending input to not look for an empty line to terminate the expression. We filed radar 19008425 to track fixing this issue.
llvm-svn: 222206
Siva Chandra