This finishes the effort to port python-wrapper.swig code over to
using PythonDataObjects.
Also included in this patch is the removal of `PyCallable` from
`python-wrapper.swig`, as it is no longer used after having been
replaced by `PythonCallable` everywhere.
There might be additional cleanup as followup patches, but it should
be all fairly simple and minor.
llvm-svn: 252939
PyCallable is a class that exists solely within the swig wrapper
code. PythonCallable is a more generic implementation of the same
idea that can be used by any Python-related interop code, and lives
in PythonDataObjects.h
The CL is mostly mechanical, and it doesn't cover every possible
user of PyCallable, because I want to minimize the impact of this
change (as well as making it easier to figure out what went wrong
in case this causes a failure). I plan to finish up the rest of
the changes in a subsequent patch, culminating in the removal of
PyCallable entirely.
llvm-svn: 252906
This had been relegated to a simple forwarding function, so just
delete it in preparation of migrating all of these functions out
of python-wrapper.swig.
llvm-svn: 252803
This only begins to port python-wrapper.swig over. Since this
code can be pretty hairy, I plan to do this incrementally over a
series of patches, each time removing or converting more code
over to the PythonDataObjects code.
llvm-svn: 252788
Fixed a crash that would happen if you tried to get the name of a constructor or destructor by calling "getDeclName()" instead of calling getName() (which would assert and crash).
Added the ability to get function arguments names from SBFunction.
llvm-svn: 252622
Relying on manual Python C API calls is error prone, especially
when trying to maintain compatibility with Python 2 and Python 3.
This patch additionally fixes what appears to be a potentially
serious memory leak, in that were were incref'ing two values
returned from the session dictionary but never decref'ing them.
There was a comment indicating that it was intentional, but the
reasoning was, I believe, faulty and it resulted in a legitimate
memory leak.
Switching everything to PythonObject based classes solves both
the compatibility issues as well as the resource leak issues.
llvm-svn: 252536
For language that support such a thing, this API allows to ask whether a type is anonymous (i.e. has been given no name)
Comes with test case
llvm-svn: 252390
Python has a complicated mechanism of checking an objects truthity.
This involves a number of steps, which end with calling two private
methods on an object (if they are implemented). In Python 2 these
two methods are `__nonzero__` and `__len__`, and in Python 3 they
are `__bool__` and `__len__`. Because we *also* define a __len__
method for certain iterable types, this was triggering a situation
in Python 3 where `__nonzero__` wasn't defined, so it was calling
`__len__`, which was returning 0 (for example an SBDebugger with
no targets), and as a result the truthosity was determined to be
False.
We fix this by correctly using ` __bool__` for Python 3, and leave
the behavior under Python 2 unchanged.
Note that this fix is only implemented in the SWIG generation
python script, and not the SWIG generation shell script. Someone
more familiar than me with shell scripts will need to fix them
to support this for Python 3 if desired.
llvm-svn: 252382
instance:
break set -l c++ -r Name
will only break on C++ symbols that match Name, not ObjC or plain C symbols. This also works
for "break set -n" and there are SB API's to pass this as well.
llvm-svn: 252356
Summary:
Code that tried to find swig and then split the path into
a separate path and filename is being removed. The invoking
build system always provides the location of swig and we
don't need to split it into 2 pieces only to recombine it
a short time later.
Reviewers: zturner, domipheus
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14415
llvm-svn: 252330
Summary:
This does a broad first pass on cleaning up a lot of the noise when
using pylint on these scripts. It mostly addresses issues of:
* Mixed tabs and spaces.
* Trailing whitespace.
* Semicolons where they aren't needed.
* Incorrect whitespace around () and [].
* Superfluous parentheses.
There will be subsequent patches with further changes that build
upon these.
Reviewers: zturner, domipheus
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14375
llvm-svn: 252244
This reverts commit e59c95ca936f5a0a8abb987b8605fd8bf82b03b6.
This was a mistake on my part. The real problem was with my
environment. I was using a release interpreter to try to load
my debug extension module. I noticed this after I finally managed
to get into my extension module's init method, and then it segfaulted
with heap errors due to mismatched CRT (debug vs. release)
llvm-svn: 252030
In Python 2, a debug extension module required an _d suffix, so
for example the extension module `_lldb` would be backed by the file
`_lldb_d.pyd` if built in debug mode, and `_lldb.pyd` if built in
release mode. In Python 2, although undocumented, this seems to
no longer be the case, and even for a debug extension module, the
interpreter will only look for the `_lldb.pyd` name.
llvm-svn: 252026
This has apparently been broken since June, but only on non-Windows.
Perhaps nobody noticed it because if the symlink is already there
it won't try to re-create it, and nobody ever tried doing a clean
build.
In any case, I will let the original author attempt to fix this if
he is still interested. the problem is that in the normal case
of not setting BUILD_SHARED_LIBS and simply running ninja, it would
link _lldb.so to a non-existent location, creating a dangling
symlink.
llvm-svn: 251840
Summary:
Along with this, support for an optional argument to the "num_children"
method of a Python synthetic child provider has also been added. These have
been added with the following use case in mind:
Synthetic child providers currently have a method "has_children" and
"num_children". While the former is good enough to know if there are
children, it does not give any insight into how many children there are.
Though the latter serves this purpose, calculating the number for children
of a data structure could be an O(N) operation if the data structure has N
children. The new method added in this change provide a middle ground.
One can call GetNumChildren(K) to know if a child exists at an index K
which can be as large as the callers tolerance can be. If the caller wants
to know about children beyond K, it can make an other call with 2K. If the
synthetic child provider maintains state about it counting till K
previosly, then the next call is only an O(K) operation. Infact, all
calls made progressively with steps of K will be O(K) operations.
Reviewers: vharron, clayborg, granata.enrico
Subscribers: labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D13778
llvm-svn: 250930
This makes LLDB launch and create a REPL, specifying no target so that the REPL
can create one for itself. Also added the "--repl-language" option, which
specifies the language to use. Plumbed the relevant arguments and errors
through the REPL creation mechanism.
llvm-svn: 250773
Python requires that Python.h is included before any std header. Not doing so
results in conflicts with standards macros such as `_XOPEN_SOURCE`. NFC.
llvm-svn: 250673
Using the Python native C API is non-portable across Python versions,
so this patch changes them to use the `PythonFile` class which hides
the version specific differences behind a single interface.
llvm-svn: 250525
a few days now where compiler-rt gets an error when trying
to run its install step (related to not being able to find
an ios version of a dylib), breaking the lldb build. I
don't know if I'm the only one seeing this or if everyone has
been doing the same hack I've been doing - removing the
compiler-rt project from the default checkout.
It's only used for the ASAN test case. So I'm temporarily
checking in my hackaround of not checking out compiler-rt
by default, I'll try to get back and look at what's actually
happening in the compiler-rt install step that is causing
the problems when built as a part of lldb.
llvm-svn: 250487
Added the ability to specify if an attach by name should be synchronous or not in SBAttachInfo and ProcessAttachInfo.
<rdar://problem/22821480>
llvm-svn: 249361
Summary:
This should be a mandatory build process going forward, if Python
is enabled. The longer term desire is to remove the old shell
scripts entirely.
Reviewers: zturner, clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12667
llvm-svn: 246979
Summary: lldb::tid_t is 64 bit, but "long" need not always be 64 bit.
Reviewers: chying, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12650
llvm-svn: 246885
Summary:
This doesn't exist in other LLVM projects any longer and doesn't
do anything.
Reviewers: chaoren, labath
Subscribers: emaste, tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D12586
llvm-svn: 246749
debugging optimized code. Adds new methods on Function/SBFunction
to query whether a given function is optimized. Adds a new
function.is-optimized format entity and changes the default
frame-format to append "[opt]" if the function was built with
optimization.
The only indication that a binary was built with optimization
that we have right now is the presence of the DW_AT_APPLE_optimized
attribute (DW_FORM_flag value 1) in the DW_TAG_compile_unit.
The absence of this flag may mean that the compile_unit was not
compiled with optimization, or it may mean that the producer
does not generate this attribute.
Currently this only works for dSYM debugging. When we create
the CompileUnit with dwarf-in-.o-file debugging we don't have
the attribute value yet so it's not set. I need to find the
flag value when we do start to read the .o file DWARF and
set the CompileUnit's status at that point - but haven't
done it yet.
I'm also going to add a mechanism for issuing warnings to users
such that they're only issued once in a debug session and
there is away for users to suppress these warnings altogether
via .lldbinit file settings. But I want to get this changeset
committed now that it's at a useful state.
<rdar://problem/19281172>
llvm-svn: 243508
Summary:
- Consolidate Unix signals selection in UnixSignals.
- Make Unix signals available from platform.
- Add jSignalsInfo packet to retrieve Unix signals from remote platform.
- Get a copy of the platform signal for each remote process.
- Update SB API for signals.
- Update signal utility in test suite.
Reviewers: ovyalov, clayborg
Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D11094
llvm-svn: 242101
This API is currently a no-op (in the sense that it has the same behavior as the already existing GetName()), but is meant long-term to provide a best-for-visualization version of the name of a function
It is still not hooked up to the command line 'bt' command, nor to the 'gui' mode, but I do have ideas on how to make that work going forward
rdar://21203242
llvm-svn: 241482
Summary:
Several changes to fix CMake builds of LLDB with the
BUILD_SHARED_LIBS setting on.
- Force all internal libraries to be built STATIC.
- Add additional library dependencies (pthread, dl,
runtimedyld).
- modify finalisation of SWIG wrapper to symlink the
"lib" dir into python/site-packages, so _lldb.so's
RPATH resolves.
Test Plan: Verified one test case with "dotest.py".
Reviewers: sylvestre.ledru, zturner
Reviewed By: zturner
Subscribers: zturner, ted, tberghammer, emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D10157
llvm-svn: 239007
lldb::addr_t SBFrame::GetCFA();
This gets the CFA (call frame address) of the frame so it allows us to take an address that is on the stack and figure out which thread it comes from.
Also modified the heap.py module to be able to find out which variable in a frame's stack frame contains an address. This way when ptr_refs finds a match on the stack, it get then report which variable contains the pointer.
llvm-svn: 238393
expr_options = lldb.SBExpressionOptions()
expr_options.SetPrefix('''
struct Foo {
int a;
int b;
int c;
}
'''
expr_result = frame.EvaluateExpression ("Foo foo = { 1, 2, 3}; foo", expr_options)
This fixed a current issue with ptr_refs, cstr_refs and malloc_info so that they can work. If expressions define their own types and then return expression results that use those types, those types get copied into the target's AST context so they persist and the expression results can be still printed and used in future expressions. Code was added to the expression parser to copy the context in which types are defined if they are used as the expression results. So in the case of types defined by expressions, they get defined in a lldb_expr function and that function and _all_ of its statements get copied. Many types of statements are not supported in this copy (array subscript, lambdas, etc) so this causes expressions to fail as they can't copy the result types. To work around this issue I have added code that allows expressions to specify an expression specific prefix. Then when you evaluate the expression you can pass the "expr_options" and have types that can be correctly copied out into the target. I added this as a way to work around an issue, but I also think it is nice to be allowed to specify an expression prefix that can be reused by many expressions, so this feature is very useful.
<rdar://problem/21130675>
llvm-svn: 238365
Summary:
Move scripts/Python/interface to scripts/interface so that we
can start making iterative improvements towards sharing the
interface files between multiple languages (each of which would
have their own directory as now).
Test Plan: Build and see.
Reviewers: zturner, emaste, clayborg
Reviewed By: clayborg
Subscribers: mjsabby, lldb-commits
Differential Revision: http://reviews.llvm.org/D9212
llvm-svn: 235676
Previously we would pass an argument to finishSwigWrapperClasses.py which
specified whether this was a debug or a release build. But sometimes
CMAKE_BUILD_TYPE would not be set to anything, causing this argument
to be empty when passed in. The only purpose of this argument was to
determine whether or not to append _d to the extension module when
creating the symlink. This is only necessary when doing a debug
build of LLDB on Windows, which implies a debug interpreter, so we
replace this with a check to see if the running interpreter is a debug
one, and append _d if so.
llvm-svn: 235559
This patch deprecates the three Python CMake variables in favor of
a single variable PYTHON_HOME which points to the root of a python
installation. Since building Python doesn't output the files in
a structure that is compatible with the PYTHONHOME environment
variable, we also provide a script install_custom_python.py which
will copy the output of a custom python build to the correct
directory structure.
The supported workflow after this patch will be to build python
once for each configuration and architecture {Debug,Release} x {x86,x64}
and then run the script. Then run CMake specifying -DPYTHON_HOME=<path>
The first time you do this will probably require you to delete your
CMake cache.
The old workflow is still supported during a transitionary period,
but a warning is printed at CMake time, and this will eventually
be removed.
Differential Revision: http://reviews.llvm.org/D8979
llvm-svn: 234660
This patch fixes the swig generation scripts to use os.path.join
instead, which produces correctly normalized paths for platforms
that don't use the standard forward slash separator.
llvm-svn: 234030
The order of libraries passed to the linker didn't work under linux (you
need the llvm libraries first, then the lldb libraries). I modelled this
after clang's setup here. Seemed simple enough to just be consistent.
llvm-svn: 232461
Summary:
Also, change its return type to size_t to match the return types of
its callers.
With this change, std::vector and std::list data formatter tests
pass on Linux (when using libstdc++) with clang as well as with gcc.
These tests have also been enabled in this patch.
Test Plan: dotest.py -p <TestDataFormatterStdVector|TestDataFormatterStdList>
Reviewers: vharron, clayborg
Reviewed By: clayborg
Subscribers: zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D8337
llvm-svn: 232399
Previously it would only regenerate LLDBWrapPython.cpp if one of
the .i files changed, or if lldb.swig changed. This patch also
makes it depend on the rest of the *.swig files, so that if any
of them changes it regenerates the CMake.
llvm-svn: 232175
This works by creating a command backed by a class whose interface should - at least - include
def __init__(self, debugger, session_dict)
def __call__(self, args, return_obj, exe_ctx)
What works:
- adding a command via command script add --class
- calling a thusly created command
What is missing:
- support for custom help
- test cases
The missing parts will follow over the next couple of days
This is an improvement over the existing system as:
a) it provides an obvious location for commands to provide help strings (i.e. methods)
b) it allows commands to store state in an obvious fashion
c) it allows us to easily add features to script commands over time (option parsing and subcommands registration, I am looking at you :-)
llvm-svn: 232136
Summary:
These functions were added in 2013, but not added to the SWIG
bindings.
Reviewers: ki.stfu, clayborg
Reviewed By: ki.stfu, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7909
llvm-svn: 230646
This is generating problems when you have built both debug and
release python. For now I just want to get CMake to work, I
will work on a more robust fix later. In the meantime you may
need to copy python27(_d).dll manually to ninja\bin after
building.
llvm-svn: 230379
Previos version of this patch (see r229148) contained two errors:
* make_symlink_darwin_debug passes 2 arguments into make_symlink, but it required 4 arguments (was fixed by r229159)
* make_symlink doesn't work on OS X
As a quick fix, the r229148 and the r229159 were reverted. Now these errors are fixed.
Summary:
This patch fixes the following tests on OS X:
```
FAIL: test_with_dsym (TestLaunchWithGlob.LaunchWithGlobTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/lldbtest.py", line 456, in wrapper
return func(self, *args, **kwargs)
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/functionalities/launch_with_glob/TestLaunchWithGlob.py", line 21, in test_with_dsym
self.do_test ()
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/functionalities/launch_with_glob/TestLaunchWithGlob.py", line 42, in do_test
self.runCmd("process launch -G true -w %s -- fi*.tx?" % (os.getcwd()))
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/lldbtest.py", line 1953, in runCmd
msg if msg else CMD_MSG(cmd))
AssertionError: False is not True : Command 'process launch -G true -w /Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/functionalities/launch_with_glob -- fi*.tx?' returns successfully
Config=x86_64-clang
======================================================================
FAIL: test_with_dwarf (TestLaunchWithGlob.LaunchWithGlobTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/lldbtest.py", line 473, in wrapper
return func(self, *args, **kwargs)
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/functionalities/launch_with_glob/TestLaunchWithGlob.py", line 28, in test_with_dwarf
self.do_test ()
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/functionalities/launch_with_glob/TestLaunchWithGlob.py", line 42, in do_test
self.runCmd("process launch -G true -w %s -- fi*.tx?" % (os.getcwd()))
File "/Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/lldbtest.py", line 1953, in runCmd
msg if msg else CMD_MSG(cmd))
AssertionError: False is not True : Command 'process launch -G true -w /Users/testuser/build/workspace/LLDB_master_release_OSX/llvm_master/tools/lldb/test/functionalities/launch_with_glob -- fi*.tx?' returns successfully
```
Reviewers: epertoso, emaste, abidh, clayborg, zturner
Reviewed By: clayborg
Subscribers: abidh, lldb-commits, emaste, epertoso, zturner, clayborg
Differential Revision: http://reviews.llvm.org/D7550
llvm-svn: 229517
Reverting this commit led to other failures which I did not see at
first. This turned out to be an easy problem to fix, so I added
SBVariablesOptions.cpp to the CMakeLists.txt. In the future please
try to make sure new files are added to CMake.
llvm-svn: 229516
Summary:
os.remove might throw an exception (of type OSError), if given file
doesn't exist. Catch the exception, and ignore it //iff// errno is
ENOENT. Rethrow the exception, if errno is not ENOENT.
Reviewers: emaste
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6362
llvm-svn: 229334
We talked about it internally - and came to the conclusion that it's time to have an options class
This commit adds an SBVariablesOptions class and goes through all the required dance
llvm-svn: 228975
SBTarget::BreakpointCreateBySourceRegex that takes file spec lists to the Python interface,
and add a test for this.
<rdar://problem/19805037>
llvm-svn: 228938
A runtime support value is a ValueObject whose only purpose is to support some language runtime's operation, but it does not directly provide any user-visible benefit
As such, unless the user is working on the runtime support, it is mostly safe for them not to see such a value when debugging
It is a language runtime's job to check whether a ValueObject is a support value, and that - in conjunction with a target setting - is used by frame variable and target variable
SBFrame::GetVariables gets a new overload with yet another flag to dictate whether to return those support values to the caller - that which defaults to the setting's value
rdar://problem/15539930
llvm-svn: 228791
Summary:
I don't know if there is a better way for the change in source/Host/freebsd/ThisThread.cpp
Reviewers: emaste
Subscribers: hansw, emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D7441
llvm-svn: 228710
This patch fixes test_launch_in_terminal test which doesn't work
in OS X since the moment as it was added in r225284. The test fails
because Target::Launch returns the following error: "the darwin-debug
executable doesn't exist at
<output_dir>/lib/python2.7/site-packages/lldb/darwin-debug'".
Patch by Ilia K
Differential Revision: http://reviews.llvm.org/D7102
llvm-svn: 227096
On Windows we copy python27(_d).dll to the bin directory. We do
this by looking at the PYTHON_LIBRARY specified by the user, which
is something like C:\foo\python27_d.lib, and replacing ".lib" with
".dll". But ".lib" as a regex will also match "flib", etc. So
make this a literal . instead of a wildcard .
llvm-svn: 226858
This reverts commit r226679. For some reason it was
not generating the same behavior as manually specifying
the include dir, library path, and exe path, and it was
causing the test suite to fail to run.
llvm-svn: 226683
CMake FindPythonLibs will look for multiple versions of Python
including both debug and release, and build up a list such as
(debug <debugpath> optimized <optimizedpath>). This confuses
the logic we have in CMake to copy the correct python dll to
the output directory so that it need not be in your system's PATH.
To alleviate this, we manually split this list and extract out
the debug and release versions of the python library, and copy
only the correct one to the output directory.
llvm-svn: 226679
`ninja lldb` used to always run "echo -n", which on OS X results in literally
echoing "-n" to the screen. Just remove the command from add_custom_target,
then it only adds an alias and `ninja lldb` now reports "no work to do".
Other than that, no intended behavior change.
llvm-svn: 226233
When Python does not exist on the system path, LLDB will be unable
to load it. Fix this by copying the dll to the output folder so
it will be side-by-side with lldb.exe.
llvm-svn: 225218
variable (now provided both by the normal parent LLVM CMake files and by
the LLVMConfig.cmake file used by the standalone build).
This allows LLDB to build into and install into correctly suffixed
libdirs. This is especially significant for LLDB because the python
extension building done by CMake directly uses multilib suffixes when
the host OS does, and the host OS will not always look back and forth
between them. As a consequence, before LLVM, Clang, and LLDB (and every
other subproject) had support for using LLVM_LIBDIR_SUFFIX, you couldn't
build or install LLDB on a multilib system with its python extensions
enabled. With this patch (on top of all the others I have submitted
throughout the project), I'm finally able to build and install LLDB on
my system with Python support enabled. I'm also able to actually run the
LLDB test suite, etc. Now, a *huge* number of the tests still fail on my
Linux system, but hey, actually running them and them testing the
debugger is a huge step forward. =D
llvm-svn: 224930
names can then be used in place of breakpoint id's or breakpoint id
ranges in all the commands that operate on breakpoints.
<rdar://problem/10103959>
llvm-svn: 224392
Our actual view of registers is a set of register sets, each one of which contains a subset of the actual registers
This makes trivial scripting operations tedious ("I just want to read r7!")
This helper allows things like: print lldb.frame.reg["r7"]
Fixes rdar://19185662
llvm-svn: 224275
Such a persisted version is equivalent to evaluating the value via the expression evaluator, and holding on to the $n result of the expression, except this API can be used on SBValues that do not obviously come from an expression (e.g. are the result of a memory lookup)
Expose this via SBValue::Persist() in our public API layer, and ValueObject::Persist() in the lldb_private layer
Includes testcase
Fixes rdar://19136664
llvm-svn: 223711
like tgmath.h and stdarg.h into the LLDB installation,
and then finding them through the Host infrastructure.
Also add a script to actually do this on Mac OS X.
llvm-svn: 223430
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
Fixed include:
- Change Platform::ResolveExecutable(...) to take a ModuleSpec instead of a FileSpec + ArchSpec to help resolve executables correctly when we have just a path + UUID (no arch).
- Add the ability to set the listener in SBLaunchInfo and SBAttachInfo in case you don't want to use the debugger as the default listener.
- Modified all places that use the SBLaunchInfo/SBAttachInfo and the internal ProcessLaunchInfo/ProcessAttachInfo to not take a listener as a parameter since it is in the launch/attach info now
- Load a module's sections by default when removing a module from a target. Since we create JIT modules for expressions and helper functions, we could end up with stale data in the section load list if a module was removed from the target as the section load list would still have entries for the unloaded module. Target now has the following functions to help unload all sections a single or multiple modules:
size_t
Target::UnloadModuleSections (const ModuleList &module_list);
size_t
Target::UnloadModuleSections (const lldb::ModuleSP &module_sp);
llvm-svn: 222167
Two flags are introduced:
- preferred display language (as in, ObjC vs. C++)
- summary capping (as in, should a limit be put to the amount of data retrieved)
The meaning - if any - of these options is for individual formatters to establish
The topic of a subsequent commit will be to actually wire these through to individual data formatters
llvm-svn: 221482
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
New functions to give client applications to tools to discover target byte sizes
for addresses prior to ReadMemory. Also added GetPlatform and ReadMemory to the
SBTarget class, since they seemed to be useful utilities to have.
Each new API has had a test case added.
http://reviews.llvm.org/D5867
llvm-svn: 220372
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
Reviewed at http://reviews.llvm.org/D5738
This adds an SB API into SBProcess:
bool SBProcess::IsInstrumentationRuntimePresent(InstrumentationRuntimeType type);
which simply tells whether a particular InstrumentationRuntime (read "ASan") plugin is present and active.
llvm-svn: 219560
Zachary Turner