summaryrefslogtreecommitdiffstats
path: root/lldb/scripts/Python/interface
Commit message (Collapse)AuthorAgeFilesLines
* Shuffle APIs around a little bit, so that if you pass custom summary ↵Enrico Granata2014-11-181-1/+2
| | | | | | options, we don't end up caching the summary hence obtained. You may want to obtain an uncapped summary, but this should not be reflected in the summary we cache. The drawback is that we don't cache as aggressively as we could, but at least you get to have different summaries with different options without having to reset formatters or the SBValue at each step llvm-svn: 222280
* Add documentation for the SBTarget::ReadInstructions andJason Molenda2014-11-181-2/+27
| | | | | | | | | SBTarget::GetInstructions APIs so it's a little clearer to understand which should be used. <rdar://problem/18787018> llvm-svn: 222225
* Add APIs on SBFunction and SBCompileUnit to inquire about the language type ↵Enrico Granata2014-11-172-0/+6
| | | | | | that the function/compile unit is defined in llvm-svn: 222189
* Fixed more fallout from running the test suite remotely on iOS devices.Greg Clayton2014-11-171-0/+12
| | | | | | | | | | | | | | | | 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
* Do not override the existing definition of addr_size when adding new ↵Enrico Granata2014-11-131-2/+2
| | | | | | properties to SBTarget. Fixes rdar://18963842 llvm-svn: 221850
* Introduce the notion of "type summary options" as flags that can be passed ↵Enrico Granata2014-11-062-1/+28
| | | | | | | | | | | | | down to individual summary formatters to alter their behavior in a formatter-dependent way 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
* Add a few functions to SBType to handle arrays and typedefs. Fixes ↵Enrico Granata2014-10-281-0/+9
| | | | | | rdar://12675166 llvm-svn: 220824
* Added functions to the C++ API, for the benefit of non-8-bit byte architectures.Matthew Gardiner2014-10-222-0/+105
| | | | | | | | | | | | 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
* Expose the type-info flags at the public API layer. These flags provide much ↵Enrico Granata2014-10-211-0/+3
| | | | | | more informational content to consumers of the LLDB API than the existing TypeClass. Part of the fix for rdar://18517593 llvm-svn: 220322
* This adds a "batch mode" to lldb kinda like the gdb batch mode. It will ↵Jim Ingham2014-10-142-1/+11
| | | | | | | | | | | | | | | | quit the debugger 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
* Add a IsInstrumentationRuntimePresent SB APIKuba Brecka2014-10-111-0/+3
| | | | | | | | | | 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
* Rework the way we pass "run multiple command" options to the various API's thatJim Ingham2014-10-112-3/+70
| | | | | | | | | | | | | | | 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
* LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and ↵Kuba Brecka2014-10-101-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | report data extraction 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
* Add a new SBExecutionContext class that wraps an ExecutionContextRef. This ↵Enrico Granata2014-10-011-0/+42
| | | | | | class is a convenient way at the API level to package a target,process,thread and frame all together - or just a subset of those llvm-svn: 218808
* This checkin is the first step in making the lldb thread stepping mechanism ↵Jim Ingham2014-09-292-0/+126
| | | | | | | | | | | | more accessible from the user level. It adds the ability to invent new stepping modes implemented by python classes, and to view the current thread plan stack and to some extent alter it. I haven't gotten to documentation or tests yet. But this should not cause any behavior changes if you don't use it, so its safe to check it in now and work on it incrementally. llvm-svn: 218642
* Fix for 218140 for SBTarget.i, the added functions were in the wrong class ↵Carlo Kok2014-09-191-10/+11
| | | | | | definition llvm-svn: 218147
* Adds two new functions to SBTarget FindGlobalVariables and ↵Carlo Kok2014-09-191-0/+9
| | | | | | FindGlobalFunctions that lets you search by name, by regular expression and by starts with. llvm-svn: 218140
* Extend the member function discovery APIs to also support Objective-C as ↵Enrico Granata2014-09-191-0/+9
| | | | | | | | | well as C++ For the Objective-C case, we do not have a "function type" notion, so we actually end up wrapping the clang ObjCMethodDecl in the Impl object, and ask function-y questions of it In general, you can always ask for return type, number of arguments, and type of each argument using the TypeMemberFunction layer - but in the C++ case, you can also acquire a Type object for the function itself, which instead you can't do in the Objective-C case llvm-svn: 218132
* Change SBType.GetMemberFunctionAtIndex() to return an object describing the ↵Enrico Granata2014-09-151-1/+30
| | | | | | member function in more detail. A type was really quite vague. This now has function name, kind, as well as function type llvm-svn: 217828
* Add logic to LLDB to figure out the types of member functions of C++ ↵Enrico Granata2014-09-121-0/+6
| | | | | | classes. Add plumbing for that all the way up to the SB layer llvm-svn: 217701
* Implement ASan history threads in SB APIKuba Brecka2014-09-061-0/+3
| | | | | | | | | Reviewed at http://reviews.llvm.org/D5219 and http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140901/012809.html llvm-svn: 217300
* Expose the ability to retrieve the result of a type validator via the SB ↵Enrico Granata2014-09-061-0/+3
| | | | | | API. To keep it simple, do not expose the pair, but just return a NULL string for success, and a non-NULL string for error; If we were to decide to expose the pair, we would need an SBTypeValidatorResult, which is fine, but it should come as part of exposing type validators through the SB API rather than as a one-off thing. So, KISS for now llvm-svn: 217299
* Expose ThreadCollection in SB APIKuba Brecka2014-09-061-0/+38
| | | | | | | | | Reviewed at http://reviews.llvm.org/D5218 and http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140901/012828.html llvm-svn: 217296
* Make it clear that the load_addr property on SBAddress relies on lldb.target, Jim Ingham2014-08-271-1/+1
| | | | | | and so can only be used in the script interpreter. llvm-svn: 216625
* Fix some typos:Sylvestre Ledru2014-08-111-1/+1
| | | | | | | | * transfered => transferred * unkown => unknown * sucessfully => successfully llvm-svn: 215367
* Add an option to suppress the persistent result variable when running ↵Jim Ingham2014-08-081-0/+9
| | | | | | | | | | | | EvaluateExpression from Python. If you don't need to refer to the result in another expression, there's no need to bloat the persistent variable table with them since you already have the result SBValue to work with. <rdar://problem/17963645> llvm-svn: 215244
* (no commit message)Greg Clayton2014-07-301-0/+6
| | | | llvm-svn: 214319
* Enable the ability to enable debug info generation when evaluating expressions.Greg Clayton2014-07-111-1/+8
| | | | llvm-svn: 212792
* Fix typos.Bruce Mitchener2014-07-014-8/+8
| | | | llvm-svn: 212132
* This creates a valid Python API for Windows, pending some issues. The ↵Deepak Panickal2014-07-011-2/+2
| | | | | | | | | | | | | changes included are - - Ported the SWIG wrapper shell scripts to Python so that they would work on Windows too along with other platforms - Updated CMake handling to fix SWIG errors and manage sym-linking on Windows to liblldb.dll - More build fixes for Windows The pending issues are that two Python modules, termios and pexpect are not available on Windows. These are currently required for the Python command interpreter to be used from within LLDB. llvm-svn: 212111
* Fix a few typos.Bruce Mitchener2014-06-271-1/+1
| | | | llvm-svn: 211851
* Added an option to turn OFF the "detach on error" behavior that was addedJim Ingham2014-06-251-0/+6
| | | | | | | | to debugserver when launching processes. <rdar://problem/16216199> llvm-svn: 211658
* Add SBUnixSignals.iEd Maste2014-06-231-0/+74
| | | | | | From the patch posted by Russell Harmon. llvm-svn: 211534
* Add API control of the signal disposition.Todd Fiala2014-06-231-0/+3
| | | | | | | | | | | | 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
* Initial merge of some of the iOS 8 / Mac OS X Yosemite specificJason Molenda2014-06-132-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add support for inspecting enum members.Todd Fiala2014-06-022-0/+122
| | | | | | | | | Change by Russell Harmon. Xcode project updates (and all errors therein) by Todd Fiala. llvm-svn: 210046
* Introduce the concept of a "display name" for typesEnrico Granata2014-05-172-1/+7
| | | | | | | | | | | | | | | | | | | | | | 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
* Add a new SBThread::SafeToCallFunctions API; this calls over toJason Molenda2014-05-131-0/+10
| | | | | | | | | | 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
* Allow clients to control the exact path that is used to launch processes by ↵Greg Clayton2014-05-071-0/+6
| | | | | | | | | | | | | | | | adding new calls to SBLaunchInfo. The new calls are: SBFileSpec SBLaunchInfo::GetExecutableFile (); void SBLaunchInfo::SetExecutableFile (SBFileSpec exe_file, bool add_as_first_arg); <rdar://problem/16833939> llvm-svn: 208245
* Add a new SBThread::GetQueue() method to get the queue that is Jason Molenda2014-04-251-0/+13
| | | | | | | | | | 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
* Add the ability to set python breakpoint commands from the SBBreakpoint & ↵Jim Ingham2014-04-022-1/+44
| | | | | | | | | | | 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
* lldb arm64 import.Jason Molenda2014-03-292-0/+10
| | | | | | | | | | | | | | | | 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
* Add the ability from the SB API's to set the "one thread" timeoutJim Ingham2014-03-281-0/+7
| | | | | | | | for expression evaluations that try one and then all threads. <rdar://problem/15598528> llvm-svn: 205060
* Add a SBQueue::GetKind() method to retrieve the type of libdispatch queue ↵Jason Molenda2014-03-131-0/+18
| | | | | | | | (serial or concurrent). <rdar://problem/7964505> llvm-svn: 203748
* libBacktraceRecording __introspection_dispatch_queue_get_pending_items isJason Molenda2014-03-091-0/+3
| | | | | | | | | | | 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
* Plumb the EvaluateExpressionOptions::{Set,Get}StopOthers through the SB API, ↵Jim Ingham2014-02-281-0/+7
| | | | | | | | | 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
* Change the Mac OS X SystemRuntime plugin from using the placeholderJason Molenda2014-02-052-2/+21
| | | | | | | | | | | | | | 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
* Merging the iohandler branch back into main. Greg Clayton2014-01-273-63/+12
| | | | | | | | | | | | 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
* Added the ability to get the type that a typedef points to via:Greg Clayton2014-01-232-0/+6
| | | | | | | | | | 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
* Add a new way to bind a format to a type: by enum typeEnrico Granata2013-12-281-0/+8
| | | | | | | | | | | 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
OpenPOWER on IntegriCloud