See http://reviews.llvm.org/D4221 for details.
This commit allows you to control the signals that lldb will suppress, stop or forward using the Python and C++ APIs.
Change by Russell Harmon.
Xcode build system changes (and any mistakes) by Todd Fiala. Tested on MacOSX 10.9.3 and Xcode 6 beta. (Xcode 5 is hitting the dependency checker crasher on all my systems).
llvm-svn: 211526
lldb support. I'll be doing more testing & cleanup but I wanted to
get the initial checkin done.
This adds a new SBExpressionOptions::SetLanguage API for selecting a
language of an expression.
I added adds a new SBThread::GetInfoItemByPathString for retriving
information about a thread from that thread's StructuredData.
I added a new StructuredData class for representing
key-value/array/dictionary information (e.g. JSON formatted data).
Helper functions to read JSON and create a StructuredData object,
and to print a StructuredData object in JSON format are included.
A few Cocoa / Cocoa Touch data formatters were updated by Enrico
to track changes in iOS 8 / Yosemite.
Before we query a thread's extended information, the system runtime may
provide hints to the remote debug stub that it will use to retrieve values
out of runtime structures. I added a new SystemRuntime method
AddThreadExtendedInfoPacketHints which allows the SystemRuntime to add
key-value type data to the initial request that we send to the remote stub.
The thread-format formatter string can now retrieve values out of a thread's
extended info structured data. The default thread-format string picks up
two of these - thread.info.activity.name and thread.info.trace_messages.
I added a new "jThreadExtendedInfo" packet in debugserver; I will
add documentation to the lldb-gdb-remote.txt doc soon. It accepts
JSON formatted arguments (most importantly, "thread":threadnum) and
it returns a variety of information regarding the thread to lldb
in JSON format. This JSON return is scanned into a StructuredData
object that is associated with the thread; UI layers can query the
thread's StructuredData to see if key-values are present, and if
so, show them to the user. These key-values are likely to be
specific to different targets with some commonality among many
targets. For instance, many targets will be able to advertise the
pthread_t value for a thread.
I added an initial rough cut of "thread info" command which will print
the information about a thread from the jThreadExtendedInfo result.
I need to do more work to make this format reasonably.
Han Ming added calls into the pmenergy and pmsample libraries if
debugserver is run on Mac OS X Yosemite to get information about the
inferior's power use.
I added support to debugserver for gathering the Genealogy information
about threads, if it exists, and returning it in the jThreadExtendedInfo
JSON result.
llvm-svn: 210874
Rationale:
Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as
std::__1::vector<int, std::__1::allocator<....
rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code
Proposed solution:
Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name
Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point
LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem
Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice
The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one
It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type
Caveats:
- for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet.
- while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters
llvm-svn: 209072
the SystemRuntime to check if a thread will have any problems
performing an inferior function call so the driver can skip
making that function call on that thread. Often the function
call can be executed on another thread instead.
<rdar://problem/16777874>
llvm-svn: 208732
currently associated with a given thread, on relevant targets.
Change the queue detection code to verify that the queues
associated with all live threads are included in the list.
<rdar://problem/16411314>
llvm-svn: 207160
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
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
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
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
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
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
<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
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
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
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
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
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
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
//------------------------------------------------------------------
/// Get all types matching \a type_mask from debug info in this
/// module.
///
/// @param[in] type_mask
/// A bitfield that consists of one or more bits logically OR'ed
/// together from the lldb::TypeClass enumeration. This allows
/// you to request only structure types, or only class, struct
/// and union types. Passing in lldb::eTypeClassAny will return
/// all types found in the debug information for this module.
///
/// @return
/// A list of types in this module that match \a type_mask
//------------------------------------------------------------------
lldb::SBTypeList
SBModule::GetTypes (uint32_t type_mask)
//------------------------------------------------------------------
/// Get all types matching \a type_mask from debug info in this
/// compile unit.
///
/// @param[in] type_mask
/// A bitfield that consists of one or more bits logically OR'ed
/// together from the lldb::TypeClass enumeration. This allows
/// you to request only structure types, or only class, struct
/// and union types. Passing in lldb::eTypeClassAny will return
/// all types found in the debug information for this compile
/// unit.
///
/// @return
/// A list of types in this compile unit that match \a type_mask
//------------------------------------------------------------------
lldb::SBTypeList
SBCompileUnit::GetTypes (uint32_t type_mask = lldb::eTypeClassAny);
This lets you request types by filling out a mask that contains one or more bits from the lldb::TypeClass enumerations, so you can only get the types you really want.
llvm-svn: 184251
- exposing new accessors: formats/format, ..., that allow you to iterate over all formatters
e.g. sys_category = lldb.debugger.GetCategory("system").summary['char *']
- ensuring that C++-based synthetic children provider can at least print their description accurately, if nothing else
llvm-svn: 183805
Providing a Python helper SBData.CreateDataFromInt() to make an SBData out of a single integer number
It tries to use the current target, if any, for endianness and pointer size, and it picks a reasonable size on your behalf - if there is no way it can infer anything reasonable it essentially picks a 64-bit Mac as the reference model
llvm-svn: 183793
SWIG is smart enough to recognize that C++ operators == and != mean __eq__ and __ne__ in Python and do the appropriate translation
But it is not smart enough to recognize that mySBObject == None should return False instead of erroring out
The %pythoncode blocks are meant to provide those extra smarts (and they play some SWIG&Python magic to find the right function to call behind the scenes with no risk of typos :-)
Lastly, SBBreakpoint provides an == but never provided a != operator - common courtesy is to provide both
llvm-svn: 180987
