| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
SBBreakpointLocation API's.
You can either provide the function name, or function body text.
Also propagate the compilation error up from where it is checked so we can report compilation errors.
<rdar://problem/9898371>
llvm-svn: 205380
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These changes were written by Greg Clayton, Jim Ingham, Jason Molenda.
It builds cleanly against TOT llvm with xcodebuild. I updated the
cmake files by visual inspection but did not try a build. I haven't
built these sources on any non-Mac platforms - I don't think this
patch adds any code that requires darwin, but please let me know if
I missed something.
In debugserver, MachProcess.cpp and MachTask.cpp were renamed to
MachProcess.mm and MachTask.mm as they picked up some new Objective-C
code needed to launch processes when running on iOS.
llvm-svn: 205113
|
|
|
|
|
|
|
|
| |
for expression evaluations that try one and then all threads.
<rdar://problem/15598528>
llvm-svn: 205060
|
|
|
|
|
|
| |
muck with cmake builds.
llvm-svn: 203956
|
|
|
|
|
|
|
|
| |
(serial or concurrent).
<rdar://problem/7964505>
llvm-svn: 203748
|
|
|
|
|
|
|
|
|
|
|
| |
changing the data it returns; this change accepts either the old format or
the new format. It doesn't yet benefit from the new format's additions -
but I need to get this checked in so we aren't rev-locked.
Also add a missing .i entry for SBQueue::GetNumRunningItems() missing from
the last checkin.
<rdar://problem/16272115>
llvm-svn: 203421
|
|
|
|
|
|
|
|
|
| |
and make it work in RunThreadPlan.
Also remove SetStopOthers from the ThreadPlanCallFunction, because if the value you have doesn't match what is
in the EvaluateExpressionOptions the plan was passed when created it won't work correctly.
llvm-svn: 202464
|
|
|
|
|
|
|
|
| |
in lldb.svn/Makefile
* Use CPP.Flags to export the declaration. The current solution broke all builds
on http://llvm-jenkins.debian.net/
llvm-svn: 202270
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug fix for pr18841:
http://llvm.org/bugs/show_bug.cgi?id=18841
This change creates a stub Python readline.so module that does almost
nothing. Its whole purpose is to prevent Python from loading the real
module, something it does during the embedded Python interpreter's
initialization sequence (and way before lldb ever requests it within
embedded_interpreter.py).
On Ubuntu 12.04 and 13.10 x86_64, and in the Python 2.7.6 tree, the
stock Python readline module links against the GNU readline library.
This appears to be the case on all Pythons except where __APPLE__ is
defined. LLDB now requires linking against the libedit library.
Something about having both libedit.so and libreadline.so linked into
the same process space is causing the Python readline.so to trigger a
NULL memory access. I have put in a separate patch to python.org.
This suppression of embedded interpreter readline support can be
removed if at least any one of the following happens:
1. The stock python distribution accepts a patch similar to what I
submitted to Python 2.7.6's Modules/readline.c file.
2. The stock python distribution implements Modules/readline.c in
terms of libedit's readline compatibility mode (i.e. essentially
compiles it the way __APPLE__ compiles that module) under Linux.
3. a clean-room implementation of the python readline module is
implemented against libedit (either readline compatibility mode or
native libedit). This could be implemented within the readline.cpp
file that this change introduces. It cannot be a fork of python's
readline.c module due to llvm licensing.
The net effect of this change on Linux is that the embedded python's
readline support will not exist.
llvm-svn: 202243
|
|
|
|
|
|
| |
the containing process to exit() from under us
llvm-svn: 201600
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libldi library to collect extended backtrace information; switch
to the libBacktraceRecording library and its APIs. Complete the
work of adding QueueItems to Queues and allow for the QueueItems
to be interrogated about their extended backtraces in turn.
There's still cleanup and documentation to do on this code but the
code is functional and I it's a good time to get the work-in-progress
checked in.
<rdar://problem/15314027>
llvm-svn: 200822
|
|
|
|
|
|
|
|
| |
PyTuple_SetItem steals a reference to the item it inserts in the tuple
This, plus the Py_XDECREF of the tuple a few lines below, causes our session dictionary to go away after the first time a SWIG layer function is called - with disastrous effects for the first subsequent attempt to use any functionality in ScriptInterpreterPython
This fixes it
llvm-svn: 200429
|
|
|
|
|
|
|
|
|
|
|
|
| |
The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)
We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.
llvm-svn: 200263
|
|
|
|
|
|
|
|
|
|
| |
SBType SBType::GetTypedefedType();
Also added the ability to get a type by type ID from a SBModule:
SBType SBModule::GetTypeByID (lldb::user_id_t uid);
llvm-svn: 199939
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Open LLDB and run:
(lldb) script print lldb.debugger.GetInputFileHandle()
This puts the debugger into a catatonic state and all interactions seem
to enter a black hole. The reason is that executing this commnand
actually *CLOSES* the input file handle and so all input is dropped on
the floor. Oof!
The fix is simple: flush a descriptor, instead of closing it, when
transferring ownership."
llvm-svn: 198835
|
|
|
|
|
|
|
|
|
|
|
| |
The "type format add" command gets a new flag --type (-t). If you pass -t <sometype>, upon fetching the value for an object of your type,
LLDB will display it as-if it was of enumeration type <sometype>
This is useful in cases of non-contiguous enums where there are empty gaps of unspecified values, and as such one cannot type their variables as the enum type,
but users would still like to see them as-if they were of the enum type (e.g. DWARF field types with their user-reserved ranges)
The SB API has also been improved to handle both types of formats, and a test case is added
llvm-svn: 198105
|
|
|
|
|
|
| |
Suggestions and ideas for improvements most welcome
llvm-svn: 198038
|
|
|
|
|
|
|
|
|
| |
libdispatch aka Grand Central Dispatch (GCD) queues. Still fleshing out the
documentation and testing of these but the overall API is settling down so it's
a good time to check it in.
<rdar://problem/15600370>
llvm-svn: 197190
|
|
|
|
|
|
| |
of the file). Thanks to Xavier De Gaye for the patch
llvm-svn: 196933
|
|
|
|
|
|
|
|
|
|
| |
symoblicate an address based on a point in time
<rdar://problem/15314403>
This patch adds a new lldb_private::SectionLoadHistory class that tracks what shared libraries were loaded given a process stop ID. This allows us to keep a history of the sections that were loaded for a time T. Many items in history objects will rely upon the process stop ID in the future.
llvm-svn: 196557
|
|
|
|
|
|
|
|
|
| |
the installed SDK to using the current OS installed headers/libraries.
This change is to address the removal of the Python framework
from the Mac OS X 10.9 (Mavericks) SDK, and is the recommended
workaround via https://developer.apple.com/library/mac/technotes/tn2328/_index.html
llvm-svn: 195557
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example code:
remote_platform = lldb.SBPlatform("remote-macosx");
remote_platform.SetWorkingDirectory("/private/tmp")
debugger.SetSelectedPlatform(remote_platform)
connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111");
err = remote_platform.ConnectRemote(connect_options)
if err.Success():
print >> result, 'Connected to remote platform:'
print >> result, 'hostname: %s' % (remote_platform.GetHostname())
src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False)
dst = lldb.SBFileSpec()
# copy src to platform working directory since "dst" is empty
err = remote_platform.Install(src, dst);
if err.Success():
print >> result, '%s installed successfully' % (src)
else:
print >> result, 'error: failed to install "%s": %s' % (src, err)
Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories.
The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform.
The API in SBPlatform is subject to change and will be getting many new functions.
llvm-svn: 195273
|
|
|
|
|
|
|
|
|
|
| |
(and same thing to Thread base class) which can be used when looking
at an ExtendedBacktrace thread; it will try to find the IndexID() of
the original thread that was executing this backtrace when it was
recorded. If lldb can't find a record of that thread, it will return
the same value as IndexID() for the ExtendedBacktrace thread.
llvm-svn: 194912
|
|
|
|
|
|
|
| |
SBThread::GetExtendedBacktraceThread to make it more clear what is
being returned.
llvm-svn: 194531
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It completes the job of using EvaluateExpressionOptions consistently throughout
the inferior function calling mechanism in lldb begun in Greg's patch r194009.
It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which
were there for convenience. Using the EvaluateExpressionOptions removes the need for them.
Using that it gets the --debug option from Greg's patch to work cleanly.
It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't
use this option unless you KNOW your expression can't throw beyond itself. This is:
<rdar://problem/15374885>
At present this is only available through the SB API's or python.
It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether
they were set by somebody else already.
llvm-svn: 194182
|
|
|
|
|
|
|
| |
bit from the method names.
<rdar://problem/15314369>
llvm-svn: 194122
|
|
|
|
|
|
|
| |
SystemRuntime and SBThread classes.
<rdar://problem/15314369>
llvm-svn: 194111
|
|
|
|
|
|
|
|
|
|
|
| |
GetThreadOriginExtendedBacktraceTypeAtIndex methods to
SBProcess.
Add documentation for the GetQueueName and GetQueueID methods
to SBThread.
<rdar://problem/15314369>
llvm-svn: 194063
|
|
|
|
|
|
|
|
|
|
| |
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended. Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.
llvm-svn: 193983
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.
Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.
This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone. No new functionality is
added with this patch, no new subclasses of Frame exist yet.
I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.
<rdar://problem/15314068>
llvm-svn: 193907
|
|
|
|
| |
llvm-svn: 193136
|
|
|
|
|
|
| |
the existing SBThread::GetQueueName() method.
llvm-svn: 193132
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When debugging with the GDB remote in LLDB, LLDB uses special packets to discover the
registers on the remote server. When those packets aren't supported, LLDB doesn't
know what the registers look like. This checkin implements a setting that can be used
to specify a python file that contains the registers definitions. The setting is:
(lldb) settings set plugin.process.gdb-remote.target-definition-file /path/to/module.py
Inside module there should be a function:
def get_dynamic_setting(target, setting_name):
This dynamic setting function is handed the "target" which is a SBTarget, and the
"setting_name", which is the name of the dynamic setting to retrieve. For the GDB
remote target definition the setting name is 'gdb-server-target-definition'. The
return value is a dictionary that follows the same format as the OperatingSystem
plugins follow. I have checked in an example file that implements the x86_64 GDB
register set for people to see:
examples/python/x86_64_target_definition.py
This allows LLDB to debug to any archticture that is support and allows users to
define the registers contexts when the discovery packets (qRegisterInfo, qHostInfo)
are not supported by the remote GDB server.
A few benefits of doing this in Python:
1 - The dynamic register context was already supported in the OperatingSystem plug-in
2 - Register contexts can use all of the LLDB enumerations and definitions for things
like lldb::Format, lldb::Encoding, generic register numbers, invalid registers
numbers, etc.
3 - The code that generates the register context can use the program to calculate the
register context contents (like offsets, register numbers, and more)
4 - True dynamic detection could be used where variables and types could be read from
the target program itself in order to determine which registers are available since
the target is passed into the python function.
This is designed to be used instead of XML since it is more dynamic and code flow and
functions can be used to make the dictionary.
llvm-svn: 192646
|
|
|
|
|
|
|
|
|
|
|
| |
as a file path) for target-specific settings
This is implemented by means of a get_dynamic_setting(target, setting_name) function vended by the Python module, which can respond to arbitrary string names with dynamically constructed
settings objects (most likely, some of those that PythonDataObjects supports) for LLDB to parse
This needs to be hooked up to the debugger via some setting to allow users to specify which module will vend the information they want to supply
llvm-svn: 192628
|
|
|
|
|
|
|
| |
Implement SBTarget::CreateValueFromAddress() with a behavior equivalent to SBValue::CreateValueFromAddress()
(but without the need to grab an SBValue first just as a starting point to make up another SBValue out of whole cloth)
llvm-svn: 192239
|
|
|
|
| |
llvm-svn: 191933
|
|
|
|
| |
llvm-svn: 191367
|
|
|
|
|
|
|
|
|
| |
This allows the PC to be directly changed to a different line.
It's similar to the example python script in examples/python/jump.py, except implemented as a builtin.
Also this version will track the current function correctly even if the target line resolves to multiple addresses. (e.g. debugging a templated function)
llvm-svn: 190572
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This merge brings in the improved 'platform' command that knows how to
interface with remote machines; that is, query OS/kernel information, push
and pull files, run shell commands, etc... and implementation for the new
communication packets that back that interface, at least on Darwin based
operating systems via the POSIXPlatform class. Linux support is coming soon.
Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS
X Mountain Lion.
Additional improvements (not in the source SVN branch 'lldb-platform-work'):
- cmake build scripts for lldb-platform
- cleanup test suite
- documentation stub for qPlatform_RunCommand
- use log class instead of printf() directly
- reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely.
- add new logging category 'platform'
Reviewers: Matt Kopec, Greg Clayton
Review: http://llvm-reviews.chandlerc.com/D1493
llvm-svn: 189295
|
|
|
|
|
|
| |
SBProcess::ReadMemory - it will fail for anything with the high bit set.
llvm-svn: 189154
|
|
|
|
|
|
| |
easier to retrieve a register value.
llvm-svn: 187184
|
|
|
|
|
|
| |
Thanks to Daniel Malea for helping test this patch for Linux happiness!
llvm-svn: 185965
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specification is information that is required to describe a module (executable, shared library, object file, ect). This information includes host path, platform path (remote path), symbol file path, UUID, object name (for objects in .a files for example you could have an object name of "foo.o"), and target triple. Module specification can be used to create a module, or used to add a module to a target. A list of module specifications can be used to enumerate objects in container objects (like universal mach files and BSD archive files).
There are two new classes:
lldb::SBModuleSpec
lldb::SBModuleSpecList
The SBModuleSpec wraps up a lldb_private::ModuleSpec, and SBModuleSpecList wraps up a lldb_private::ModuleSpecList.
llvm-svn: 185877
|
|
|
|
|
|
|
|
| |
- build fails due to PyCallable template definition inside an extern "C" scope
This commit reverts 185240, 184893 and 184608.
llvm-svn: 185560
|
|
|
|
|
|
|
|
| |
OS Plugins' __init__ method takes two arguments: (self,process)
I was erroneously passing the session_dict as well as part of my PyCallable changes and that caused plugins to fail to work
llvm-svn: 185240
|
|
|
|
|
|
|
|
|
|
|
|
| |
The semi-unofficial way of returning a status from a Python command was to return a string (e.g. return "no such variable was found") that LLDB would pick as a clue of an error having happened
This checkin changes that:
- SBCommandReturnObject now exports a SetError() call, which can take an SBError or a plain C-string
- script commands now drop any return value and expect the SBCommandReturnObject ("return object") to be filled in appropriately - if you do nothing, a success will be assumed
If your commands were relying on returning a value and having LLDB pick that up as an error, please change your commands to SetError() through the return object or expect changes in behavior
llvm-svn: 184893
|
|
|
|
|
|
|
|
|
|
| |
Now, the way SWIG wrappers call into Python is through a utility PyCallable object, which overloads operator () to look like a normal function call
Plus, using the SBTypeToSWIGWrapper() family of functions, we can call python functions transparently as if they were plain C functions
Using this new technique should make adding new Python call points easier and quicker
The PyCallable is a generally useful facility, and we might want to consider moving it to a separate layer where other parts of LLDB can use it
llvm-svn: 184608
|
|
|
|
|
|
|
|
|
|
|
| |
and instead use a safer type-checked API (thanks templates)
Any time a SWIG wrapper needs a PyObject for an SB object, it now should call into SBTypeToSWIGWrapper<SBType>(SBType*)
If you try to use it on an SBType for which there is not an implementation yet, LLDB will fail to link - just add your specialization to python-swigsafecast.swig and rebuild
This is the first step in simplifying our SWIG Wrapper layer
llvm-svn: 184580
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functions to generate part or all of the output text
Specifically, the ${target ${process ${thread and ${frame specifiers have been extended to allow a subkeyword .script:<fctName> (e.g. ${frame.script:FooFunction})
The functions are prototyped as
def FooFunction(Object,unused)
where object is of the respective SB-type (SBTarget for target.script, ... and so on)
This has not been implemented for ${var because it would be akin to a Python summary which is already well-defined in LLDB
llvm-svn: 184500
|
|
|
|
|
|
| |
The script was able to point out and save 40 bytes in each lldb_private::Section by being very careful where we need to have virtual destructors and also by re-ordering members.
llvm-svn: 184364
|