summaryrefslogtreecommitdiffstats
path: root/lldb/source/API
Commit message (Collapse)AuthorAgeFilesLines
...
* Rework the way we pass "run multiple command" options to the various API's thatJim Ingham2014-10-112-1/+118
| | | | | | | | | | | | | | | 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/+22
| | | | | | | | | | | | | | | | | | | | | | | | | 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 disassembly-format specification so that the disassemblerJason Molenda2014-10-102-3/+30
| | | | | | | | | | | | | | | | | | | | | output style can be customized. Change the built-in default to be more similar to gdb's disassembly formatting. The disassembly-format for a gdb-like output is ${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>: The disassembly-format for the lldb style output is {${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}: The two backticks in the lldb style formatter triggers the sub-expression evaluation in CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to use ' characters instead of ` would work around that. <rdar://problem/9885398> llvm-svn: 219544
* Extend synthetic children to produce synthetic values (as in, those that ↵Enrico Granata2014-10-081-0/+4
| | | | | | | | | | | | | | | | | GetValueAsUnsigned(), GetValueAsCString() would return) The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function. If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value The rationale for doing things this way is twofold: - there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial - we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature Comes with a test case llvm-svn: 219330
* Create a ConnectionGenericFile class for Windows.Zachary Turner2014-10-061-1/+1
| | | | | | | | | | | | | This is the first step in getting ConnectionFileDescriptor ported to Windows. It implements a connection against a disk file for windows. This supports connection strings of the form file://PATH which are currently supported only on posix platforms in ConnectionFileDescriptor. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D5608 llvm-svn: 219145
* Move ConnectionFileDescriptor to platform-specific Host directory.Zachary Turner2014-10-061-1/+1
| | | | | | | | | | | | As part of getting ConnectionFileDescriptor working on Windows, there is going to be alot of platform specific work to be done. As a result, the implementation is moving into Host. This patch performs the code move and fixes up call-sites appropriately. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D5548 llvm-svn: 219143
* Fix a problem where LLDB was constructing a TypeImpl marking the dynamic ↵Enrico Granata2014-10-061-1/+1
| | | | | | type as the static type. Instead use the TypeImpl() constructor correctly llvm-svn: 219142
* Revert r219102 as it caused significant buildbot breakageEd Maste2014-10-061-4/+0
| | | | llvm-svn: 219120
* Call SBDebugger::Initialize/Terminate from within Create/Destroy.Matthew Gardiner2014-10-061-0/+4
| | | | | | | The above change permits developers using the lldb C++ API to code applications in a more logical manner. llvm-svn: 219102
* Allow Python commands to optionally take an SBExecutionContext argument in ↵Enrico Granata2014-10-012-1/+7
| | | | | | case they need to handle 'where they want to act' separately from the notion of 'currently-selected entity' that is associated to the debugger. Do this in an (hopefully) non-breaking way by running an argcount check before passing in the new argument. Update the test case to also check for this new feature. www update to follow llvm-svn: 218834
* [cmake] Include the new file in the CMake lists. Without this everyChandler Carruth2014-10-011-0/+1
| | | | | | | | | | CMake build of any part of LLVM with LLDB checked out fails immediately. =[ We appear to not even have a build bot covering the CMake build of LLDB which makes this truly terrible. That needs to be fixed immediately. llvm-svn: 218831
* Add a new SBExecutionContext class that wraps an ExecutionContextRef. This ↵Enrico Granata2014-10-011-0/+118
| | | | | | 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
* Fix cmake build for new thread plan files.Todd Fiala2014-09-301-0/+1
| | | | llvm-svn: 218679
* This checkin is the first step in making the lldb thread stepping mechanism ↵Jim Ingham2014-09-294-3/+372
| | | | | | | | | | | | 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
* Test suite runs better again after recent fixes that would select a platform ↵Greg Clayton2014-09-192-7/+31
| | | | | | | | | | | | | if a "file a.out" auto selected a different platform than the selected one. Changes include: - fix it so you can select the "host" platform using "platform select host" - change all callbacks that create platforms to returns shared pointers - fix TestImageListMultiArchitecture.py to restore the "host" platform by running "platform select host" - Add a new "PlatformSP Platform::Find(const ConstString &name)" method to get a cached platform - cache platforms that are created and re-use them instead of always creating a new one llvm-svn: 218145
* Adds two new functions to SBTarget FindGlobalVariables and ↵Carlo Kok2014-09-191-0/+84
| | | | | | 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-7/+31
| | | | | | | | | 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-4/+95
| | | | | | 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/+22
| | | | | | classes. Add plumbing for that all the way up to the SB layer llvm-svn: 217701
* Create a HostThread abstraction.Zachary Turner2014-09-091-5/+34
| | | | | | | | | | | | | This patch moves creates a thread abstraction that represents a thread running inside the LLDB process. This is a replacement for otherwise using lldb::thread_t, and provides a platform agnostic interface to managing these threads. Differential Revision: http://reviews.llvm.org/D5198 Reviewed by: Jim Ingham llvm-svn: 217460
* Implement ASan history threads in SB APIKuba Brecka2014-09-061-0/+13
| | | | | | | | | 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/+30
| | | | | | 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
* Fix CMake configuration (forgot to add a file in the last commit).Kuba Brecka2014-09-061-0/+1
| | | | llvm-svn: 217297
* Expose ThreadCollection in SB APIKuba Brecka2014-09-061-0/+97
| | | | | | | | | 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
* Update LLDB to use LLVM's DynamicLibrary.Zachary Turner2014-08-271-7/+8
| | | | | | | | | LLDB had implemented its own DynamicLibrary class for plugin support. LLVM has an equivalent mechanism, so this patch deletes the duplicated code in LLDB and updates LLDB to reference the mechanism provided by LLVM. llvm-svn: 216606
* Move the rest of the HostInfo functions over.Zachary Turner2014-08-211-1/+1
| | | | | | | | | This should bring HostInfo up to 99% completion. The remainder of code in Host will be split into instantiatable classes representing host processes, threads, dynamic libraries, and process launching strategies. llvm-svn: 216230
* Move Host::GetLLDBPath to HostInfo.Zachary Turner2014-08-211-2/+3
| | | | | | | | This continues the effort to get Host code moved over to HostInfo, and removes many more instances of preprocessor defines along the way. llvm-svn: 216195
* Buffer not null terminated CID 1094354Sylvestre Ledru2014-08-191-0/+1
| | | | llvm-svn: 215976
* Add an option to suppress the persistent result variable when running ↵Jim Ingham2014-08-081-0/+13
| | | | | | | | | | | | 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
* Optimizations for FileSpec.Zachary Turner2014-08-071-1/+7
| | | | llvm-svn: 215124
* (no commit message)Greg Clayton2014-07-302-0/+13
| | | | llvm-svn: 214319
* SBCommunication: Fix a pointer-to-function to void-pointer castDavid Majnemer2014-07-221-1/+1
| | | | | | | | | | reinterpret_cast may not convert a pointer-to-function to a void-pointer. Take a detour through intptr_t and *then* convert to a pointer-to-function. This fixes a diagnostic emitted by GCC. llvm-svn: 213696
* SBHostOS: Fix a pointer-to-function to void-pointer castDavid Majnemer2014-07-221-1/+1
| | | | | | | | | | | | reinterpret_cast may not convert a pointer-to-function to a void-pointer. Take a detour through intptr_t and *then* convert to a pointer-to-function. This fixes a warning emitted by GCC. Differential Revision: http://reviews.llvm.org/D4624 llvm-svn: 213692
* Fix some warnings in the Windows build.Zachary Turner2014-07-161-1/+1
| | | | llvm-svn: 213194
* Any commands that are executed through the public interface using ↵Greg Clayton2014-07-151-0/+1
| | | | | | | | | | | | | | SBCommandInterpreter::HandleCommand() are assumed to be in non-interactive mode. Any commands that want interactivity (stdin) will need to be executed through the normal command interpreter using the debugger's in/out/err file handles, or by using "command source". Individual commands through the API will have their STDIN disabled. The STDOUT and STDERR will be redirected into the SBCommandReturnObject argument to SBCommandInterpreter::HandleCommand() as usual. This helps with a deadlock situation in an IDE (Xcode) where the IDE was managing the breakpoint actions by setting a breakpoint callback and doing things manually. <rdar://problem/17386271> llvm-svn: 213023
* Enable the ability to enable debug info generation when evaluating expressions.Greg Clayton2014-07-111-0/+12
| | | | llvm-svn: 212792
* If a breakpoint gets deleted, any SBBreakpoints representing thatJim Ingham2014-07-021-1/+6
| | | | | | breakpoint should return false from IsValid. llvm-svn: 212206
* Fix typos.Bruce Mitchener2014-07-011-1/+1
| | | | llvm-svn: 212132
* Added an option to turn OFF the "detach on error" behavior that was addedJim Ingham2014-06-251-0/+12
| | | | | | | | to debugserver when launching processes. <rdar://problem/16216199> llvm-svn: 211658
* Fix up Windows build for the SBUnixSignals addition.Todd Fiala2014-06-241-0/+3
| | | | | | Change by Zachary Turner. llvm-svn: 211635
* Add API control of the signal disposition.Todd Fiala2014-06-233-0/+214
| | | | | | | | | | | | 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
* Remove unused variablesSaleem Abdulrasool2014-06-131-11/+0
| | | | | | | | Address the 'variable set but not used' warning from GCC. In some cases a few additional calls were removed where there should be no visible side effects of the calls (i.e. should not effect any cached state). llvm-svn: 210879
* Initial merge of some of the iOS 8 / Mac OS X Yosemite specificJason Molenda2014-06-132-0/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-023-0/+217
| | | | | | | | | Change by Russell Harmon. Xcode project updates (and all errors therein) by Todd Fiala. llvm-svn: 210046
* Don't allow two threads to both be in SBDebugger::Create() due to threading ↵Greg Clayton2014-05-191-0/+9
| | | | | | | | issues in FormatManager. <rdar://problem/16937126> llvm-svn: 209160
* Introduce the concept of a "display name" for typesEnrico Granata2014-05-172-0/+33
| | | | | | | | | | | | | | | | | | | | | | 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/+9
| | | | | | | | | | 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-15/+30
| | | | | | | | | | | | | | | | 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
* Rename eExecution*** to eExpression*** to be consistent with the result type.Jim Ingham2014-05-052-2/+2
| | | | llvm-svn: 207945
* Make the Expression Execution result enum available to the SB API layer.Jim Ingham2014-05-053-2/+8
| | | | | | | | | Add a callback that will allow an expression to be cancelled between the expression evaluation stages (for the ClangUserExpressions.) <rdar://problem/16790467>, <rdar://problem/16573440> llvm-svn: 207944
OpenPOWER on IntegriCloud