"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
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
Failure to install python packages now fails the make install.
This patch properly handles the optional DESTDIR variable.
Patch by Todd Fiala
llvm-svn: 196624
<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
Summary:
- Stop to try to rebuild llvm on each invocation by removing the invalid library entry libLLVMArchive.a which no longer exists.
- Remove the useless ranlib invocation. "libtools -static" automatically takes care of the archive table of content.
CC: lldb-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2296
llvm-svn: 196128
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
SmallPtrSet.cpp use different methods if SmallPtrSet.h is included
in C++11 mode. Building llvm in C++03 mode and lldb in C++11 mode
resulted in a link-time failure with the C++11-mode-specific method
not being found in the llvm build.
llvm-svn: 195544
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
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
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
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
Enrico Granata
Jason Molenda
Sylvestre Ledru
Greg Clayton
Jean-Daniel Dupas
Sean Callanan
Jim Ingham