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
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
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
Reviewed at http://reviews.llvm.org/D5592
This patch gives LLDB some ability to interact with AddressSanitizer runtime library, on top of what we already have (historical memory stack traces provided by ASan). Namely, that's the ability to stop on an error caught by ASan, and access the report information that are associated with it. The report information is also exposed into SB API.
More precisely this patch...
adds a new plugin type, InstrumentationRuntime, which should serve as a generic superclass for other instrumentation runtime libraries, these plugins get notified when modules are loaded, so they get a chance to "activate" when a specific dynamic library is loaded
an instance of this plugin type, AddressSanitizerRuntime, which activates itself when it sees the ASan dynamic library or founds ASan statically linked in the executable
adds a collection of these plugins into the Process class
AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
the StopInfo superclass is extended with a m_extended_info field (it's a StructuredData::ObjectSP), that can hold arbitrary JSON-like data, which is the way the new plugin provides the report data
the "thread info" command now accepts a "-s" flag that prints out the JSON data of a stop reason (same way the "-j" flag works now)
SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
adds a test case for all of this
I plan to also get rid of the original ASan plugin (memory history stack traces) and use an instance of AddressSanitizerRuntime for that purpose.
Kuba
llvm-svn: 219546
Bruce Mitchener