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
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
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
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
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
Zachary Turner