| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 222597
|
| |
|
|
| |
llvm-svn: 222594
|
| |
|
|
|
|
| |
inclined. Updates to the webdoc will follow
llvm-svn: 222593
|
| |
|
|
|
|
|
| |
SBLineEntry and SBDeclaration. Patch from Chris Willmore.
<rdar://problem/19054323>
llvm-svn: 222592
|
| |
|
|
| |
llvm-svn: 222589
|
| |
|
|
|
|
| |
not the *only* one. Rename it to reflect that
llvm-svn: 222582
|
| |
|
|
|
|
| |
in the list
llvm-svn: 222576
|
| |
|
|
|
|
| |
was split between feature-specific flags, and an m_be_raw flag, which then drove some other changes in printing behavior. Clean that up, so that each functionality has its own flag .. oh, and make the bools all go in a bitfield since I may want to add more of those over time
llvm-svn: 222548
|
| |
|
|
|
|
|
|
| |
pipe handles should be inherited by a child process.
http://reviews.llvm.org/D6348
llvm-svn: 222541
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test/api/multithreaded/test_listener_event_description.cpp to work properly on Linux/FreeBSD
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
|
| |
|
|
| |
llvm-svn: 222484
|
| |
|
|
| |
llvm-svn: 222479
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
<rdar://problem/16705325>
llvm-svn: 222459
|
| |
|
|
| |
llvm-svn: 222449
|
| |
|
|
|
|
| |
llvm.org/pr21620
llvm-svn: 222442
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: None.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6342
llvm-svn: 222440
|
| |
|
|
|
|
|
|
|
|
| |
Process/ProcessPOSIX.cpp
and FreeBSD/ProcessMonitor.
http://reviews.llvm.org/D6240
llvm-svn: 222372
|
| |
|
|
|
|
| |
StringMap::insert.
llvm-svn: 222370
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
options, we don't end up caching the summary hence obtained. You may want to obtain an uncapped summary, but this should not be reflected in the summary we cache. The drawback is that we don't cache as aggressively as we could, but at least you get to have different summaries with different options without having to reset formatters or the SBValue at each step
llvm-svn: 222280
|
| |
|
|
|
|
| |
retrieve uncapped data
llvm-svn: 222277
|
| |
|
|
| |
llvm-svn: 222276
|
| |
|
|
|
|
| |
This reverts commit aa8d370ee798f75bc05a1ae9a240bc3e5b6870ac.
llvm-svn: 222275
|
| |
|
|
| |
llvm-svn: 222273
|
| |
|
|
| |
llvm-svn: 222271
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 222246
|
| |
|
|
|
|
| |
llvm.org/21599
llvm-svn: 222245
|
| |
|
|
|
|
| |
opposite of what it says.
llvm-svn: 222243
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
SBTarget::GetInstructions APIs so it's a little clearer to
understand which should be used.
<rdar://problem/18787018>
llvm-svn: 222225
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
so it will not immediately terminate after the first regular expression in "command regex <name>" commands.
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
|
| |
|
|
|
|
| |
a read error, and reporting spurious 'unable to read data' messages. rdar://19007243
llvm-svn: 222190
|
| |
|
|
|
|
| |
that the function/compile unit is defined in
llvm-svn: 222189
|
| |
|
|
| |
llvm-svn: 222186
|
| |
|
|
|
|
|
|
| |
Previously using HostThread::GetNativeThread() required an ugly
cast to most-derived type. This solves the issue by simply returning
the derived type directly.
llvm-svn: 222185
|
| |
|
|
| |
llvm-svn: 222184
|
| |
|
|
| |
llvm-svn: 222182
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously we were directly updating the thread list and stopping
and restarting the process every time threads were created. With
this patch, we queue up thread launches and thread exits, resolve
these all internally, and only update the threads when we get an
UpdateThreadList call. We now only update the private state on
an actual stop (i.e. breakpoint).
llvm-svn: 222178
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Editline does not work correctly on Windows. This goes back at
least to r208369, and as a result r210105 was submitted to disable
libedit at runtime on Windows.
More recently, r222163 was submitted which re-writes editline
entirely, but makes the situation even worse on Windows, to the
point that it doesn't even compile. While it would be easy to
fix the compilation failure, this patch simply stops compiling
Editline entirely on Windows, as the simple compilation fix would
still result in a broken use of select on Windows, and as such a
broken implementation of Editline.
Since Editline was already disabled to begin with on Windows, we
don't attempt to fix the compilation failure or the underlying
issues, and instead just disable it "even more".
llvm-svn: 222177
|