| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
(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
|
|
|
|
|
|
| |
inclined. Updates to the webdoc will follow
llvm-svn: 222593
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
input.
Improvements include:
* Use of libedit's wide character support, which is imperfect but a distinct improvement over ASCII-only
* Fallback for ASCII editing path
* Support for a "faint" prompt clearly distinguished from input
* Breaking lines and insert new lines in the middle of a batch by simply pressing return
* Joining lines with forward and backward character deletion
* Detection of paste to suppress automatic formatting and statement completion tests
* Correctly reformatting when lines grow or shrink to occupy different numbers of rows
* Saving multi-line history, and correctly preserving the "tip" of history during editing
* Displaying visible ^C and ^D indications when interrupting input or sending EOF
* Fledgling VI support for multi-line editing
* General correctness and reliability improvements
llvm-svn: 222163
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Python summary functions
This works similarly to the {thread/frame/process/target.script:...} feature - you write a summary string, part of which is
${var.script:someFuncName}
someFuncName is expected to be declared as
def someFuncName(SBValue,otherArgument) - essentially the same as a summary function
Since . -> [] are the only allowed separators, and % is used for custom formatting, .script: would not be a legitimate symbol anyway, which makes this non-ambiguous
llvm-svn: 220821
|
|
|
|
|
|
| |
There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be.
llvm-svn: 220254
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D5805
Reviewed by: Greg Clayton
llvm-svn: 220217
|
|
|
|
| |
llvm-svn: 219915
|
|
|
|
| |
llvm-svn: 219914
|
|
|
|
|
|
|
|
| |
from the previous for() loop - check that it is non-null before trying
to deref it.
clang static analyzer fixit.
llvm-svn: 219887
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
quit the debugger
after all the commands have been executed except if one of the commands was an execution control
command that stopped because of a signal or exception.
Also adds a variant of SBCommandInterpreter::HandleCommand that takes an SBExecutionContext. That
way you can run an lldb command targeted at a particular target, thread or process w/o having to
select same before running the command.
Also exposes CommandInterpreter::HandleCommandsFromFile to the SBCommandInterpreter API, since that
seemed generally useful.
llvm-svn: 219654
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
do that (RunCommandInterpreter, HandleCommands, HandleCommandsFromFile) to gather
the options into an options class. Also expose that to the SB API's.
Change the way the "-o" options to the lldb driver are processed so:
1) They are run synchronously - didn't really make any sense to run the asynchronously.
2) The stop on error
3) "quit" in one of the -o commands will not quit lldb - not the command interpreter
that was running the -o commands.
I added an entry to the run options to stop-on-crash, but I haven't implemented that yet.
llvm-svn: 219553
|
|
|
|
|
|
|
|
|
| |
Addresses pr/21190 (http://llvm.org/bugs/show_bug.cgi?id=21190).
r219169 implemented this change list:
http://reviews.llvm.org/D5472 for more details.
llvm-svn: 219461
|
|
|
|
|
|
| |
command, be ready to use synthetic children if they are there. Those are now a source of values, so worth checking for
llvm-svn: 219452
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Python one-line execution was using ConnectionFileDescriptor to do
a non-blocking read against a pipe. This won't work on Windows,
as CFD is implemented using select(), and select() only works with
sockets on Windows.
The solution is to use ConnectionGenericFile on Windows, which uses
the native API to do overlapped I/O on the pipe. This in turn
requires re-implementing Host::Pipe on Windows using native OS
handles instead of the more portable _pipe CRT api.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D5679
llvm-svn: 219339
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GetValueAsUnsigned(), GetValueAsCString() would return)
The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function.
If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value
The rationale for doing things this way is twofold:
- there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial
- we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix
On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature
Comes with a test case
llvm-svn: 219330
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This setting contains the following:
A list containing all the arguments to be passed to the expression parser compiler.
This change also ensures quoted arguments are handled appropriately.
See http://reviews.llvm.org/D5472 for more details.
Change by Tong Shen.
llvm-svn: 219169
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of getting ConnectionFileDescriptor working on Windows,
there is going to be alot of platform specific work to be done.
As a result, the implementation is moving into Host. This patch
performs the code move and fixes up call-sites appropriately.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D5548
llvm-svn: 219143
|
|
|
|
|
|
| |
case they need to handle 'where they want to act' separately from the notion of 'currently-selected entity' that is associated to the debugger. Do this in an (hopefully) non-breaking way by running an argcount check before passing in the new argument. Update the test case to also check for this new feature. www update to follow
llvm-svn: 218834
|
|
|
|
|
|
|
|
|
|
|
|
| |
more accessible from
the user level. It adds the ability to invent new stepping modes implemented by python classes,
and to view the current thread plan stack and to some extent alter it.
I haven't gotten to documentation or tests yet. But this should not cause any behavior changes
if you don't use it, so its safe to check it in now and work on it incrementally.
llvm-svn: 218642
|
|
|
|
|
|
|
|
|
|
|
|
| |
lldb/llvm/clang/compiler-rt repos.
See http://reviews.llvm.org/D5495 for more details.
These are changes that are part of an effort to support building llgs, within the AOSP source tree, using the Android.mk
build system, when using the llvm/clang/lldb git repos from AOSP replaced with the experimental ones currently in
github.com/tfiala/aosp-{llvm,clang,lldb,compiler-rt}.
llvm-svn: 218568
|
|
|
|
|
|
|
|
|
|
|
| |
requirement for a command instead of the smallest. e.g. if a command
requires a Target, Process, Thread, and Frame, and none of those
are available, report the largest -- Target -- as being missing
instead of the smallest -- Frame.
Patch by Paul Osmialowski.
llvm-svn: 218181
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
if a "file a.out" auto selected a different platform than the selected one.
Changes include:
- fix it so you can select the "host" platform using "platform select host"
- change all callbacks that create platforms to returns shared pointers
- fix TestImageListMultiArchitecture.py to restore the "host" platform by running "platform select host"
- Add a new "PlatformSP Platform::Find(const ConstString &name)" method to get a cached platform
- cache platforms that are created and re-use them instead of always creating a new one
llvm-svn: 218145
|
|
|
|
|
|
|
|
|
|
| |
(Xcode for example).
The problem was the read_func we were supplying to the interactive interpreter wasn't stripping the newline from the end of the string. Now it does and multi-line python scripts can be typed in Xcode.
<rdar://problem/17696438>
llvm-svn: 217843
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
define a one-liner short help for their command
Also, in case they don't define any, change the default from "Run Python function <blah>" into "For more information run help <blah>"
The core issue here is that Python only allows one docstring per function, so we can't really attach both a short and a long help to the same command easily
There are alternatives but this is not a pressing enough concern to go through the motions quite yet
Fixes rdar://18322737
llvm-svn: 217795
|
|
|
|
|
|
| |
variable.
llvm-svn: 217456
|
|
|
|
|
|
| |
when compiling optimized.
llvm-svn: 217429
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes sure that nothing that requires Python is being built
when the LLDB_DISABLE_PYTHON flag is being passed in.
It also changes a use of CPPFLAGS to CPP.Flags since the former is overridden
when external flags are passed in while the later is not. I'm not sure exactly
why LLDB_DISABLE_PYTHON is in CXXFLAGS rather than CPPFLAGS,
but cleaning that up is for another commit.
Differential Revision: http://reviews.llvm.org/D4918
llvm-svn: 217414
|
|
|
|
|
|
| |
type validators. The jury is still out on what the user experience of type validators should be, so for now gate it on a specific flag. The mode I am using is prefix variables that fail to validate with a bang, and then emitting the actual validation error on a separate line. Of course, given the total absence of validators, this should never actually happen to you
llvm-svn: 217303
|
|
|
|
|
|
|
|
| |
at a time.
<rdar://problem/13314462>
llvm-svn: 216747
|
|
|
|
|
|
|
|
|
|
|
|
| |
such. This was causing:
(lldb) disassemble -n '-<TAB>
to crash.
<rdar://problem/18134531>
llvm-svn: 216626
|
|
|
|
|
|
|
|
|
| |
This should bring HostInfo up to 99% completion. The remainder
of code in Host will be split into instantiatable classes
representing host processes, threads, dynamic libraries, and
process launching strategies.
llvm-svn: 216230
|
|
|
|
|
|
|
|
| |
This continues the effort to get Host code moved over to HostInfo,
and removes many more instances of preprocessor defines along the
way.
llvm-svn: 216195
|
|
|
|
|
|
| |
warnings we compile with because of SWIG generated code.
llvm-svn: 215778
|
|
|
|
|
|
|
|
| |
(lldb) b "Foo::Bar::Baz"
<rdar://problem/11782098>
llvm-svn: 215668
|
|
|
|
|
|
|
|
| |
embedded python interpreter.
<rdar://problem/17949057>
llvm-svn: 215608
|
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4826
Reviewed by: Enrico Granata
llvm-svn: 215256
|
|
|
|
| |
llvm-svn: 214941
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CommandReturnObject. Otherwise, all the overridden command
can do is say it overrode the command, not say what it did...
Also removed the duplicate definition of CommandOverrideCallback
from the private interfaces.
Now to figure out how to get this through the SB API's...
<rdar://problem/17911629>
llvm-svn: 214938
|
|
|
|
|
|
|
|
|
|
| |
-O -S -s or specify a file on the command line.
This means TAB completion wasn't working and editline wasn't being used.
<rdar://problem/17872824>
llvm-svn: 214428
|
|
|
|
| |
llvm-svn: 214319
|
|
|
|
|
|
|
|
|
|
|
| |
Assuming that the user's home directory is at ~ is incorrect on
Windows. This patch delegates the request to LLVM's support
library, which already provides a cross-platform implementation
of this function.
Differential Revision: http://reviews.llvm.org/D4674
llvm-svn: 214093
|
|
|
|
|
|
|
|
|
| |
printf's %p format specifier expects an argument of type void-pointer,
not type PyThreadState*. Fix this with a static_cast.
Differential Revision: http://reviews.llvm.org/D4632
llvm-svn: 213695
|
|
|
|
|
|
| |
another, attempting to fix it.
llvm-svn: 213413
|
|
|
|
| |
llvm-svn: 213411
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SBCommandInterpreter::HandleCommand() are assumed to be in non-interactive mode.
Any commands that want interactivity (stdin) will need to be executed through the normal command interpreter using the debugger's in/out/err file handles, or by using "command source".
Individual commands through the API will have their STDIN disabled. The STDOUT and STDERR will be redirected into the SBCommandReturnObject argument to SBCommandInterpreter::HandleCommand() as usual.
This helps with a deadlock situation in an IDE (Xcode) where the IDE was managing the breakpoint actions by setting a breakpoint callback and doing things manually.
<rdar://problem/17386271>
llvm-svn: 213023
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes a number of issues with embedded Python on
Windows. In particular:
1) The script that builds the python modules was normalizing the
case of python filenames during copies. The module name is
the filename, and is case-sensitive, so this was breaking code.
2) Changes the build to not attempt to link against python27.lib
(e.g. the release library) when linking against msvcrt debug
library. Doing a debug build of LLDB with embedded python
support now requires you to provide your own self-compiled
debug version of python.
3) Don't import termios when initializing the interpreter. This
is part of a larger effort to remove the dependency on termios
since it is not available on Windows. This particular instance
was unnecessary and unused.
Reviewed by: Todd Fiala
Differential Revision: http://reviews.llvm.org/D4441
llvm-svn: 212785
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The getopt library has a structure called option (lowercase). We
have a structure called Option (uppercase). previously the two
structures had exactly the same definitions, and we were doing a
C-style cast of an Option* to an option*. C-style casts don't
bother to warn you when you cast to unrelated types, but in the
original OptionValidator patch I modified the definition of Option.
This patch fixes the errors by building an array of option
structures and filling it out the correct way before passing it to
the getopt library.
This also fixes one other source of test failures: an uninitialized
read that occurs due to not initializing a field of the
OptionDefinition.
Reviewed By: Todd Fiala
Differential Revision: http://reviews.llvm.org/D4425
llvm-svn: 212628
|
|
|
|
|
|
|
| |
This reverts commit ec7c94f8e6860968d384b578e5564a9c55c80b4a and
re-enables OptionValidators.
llvm-svn: 212627
|
|
|
|
|
|
|
|
| |
Change by Paul Osmialowski
See http://reviews.llvm.org/D4379 for details.
llvm-svn: 212583
|