summaryrefslogtreecommitdiffstats
path: root/lldb/source/API
Commit message (Collapse)AuthorAgeFilesLines
* Shuffle APIs around a little bit, so that if you pass custom summary ↵Enrico Granata2014-11-181-3/+6
| | | | | | 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 APIs on SBFunction and SBCompileUnit to inquire about the language type ↵Enrico Granata2014-11-172-0/+18
| | | | | | that the function/compile unit is defined in llvm-svn: 222189
* Change HostThread::GetNativeThread() to return a derived reference.Zachary Turner2014-11-171-5/+2
| | | | | | | | Previously using HostThread::GetNativeThread() required an ugly cast to most-derived type. This solves the issue by simply returning the derived type directly. llvm-svn: 222185
* Fixed more fallout from running the test suite remotely on iOS devices.Greg Clayton2014-11-172-4/+33
| | | | | | | | | | | | | | | | 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
* Fixed "SBTarget SBDebugger::CreateTarget (const char *filename)" to use the ↵Greg Clayton2014-11-131-6/+3
| | | | | | | | | | | | | | same semantics as other SBDebugger::CreateTarget() functions. The issues were: - If you called this function with any arch other than the default target architecture, creating the target would fail because the Target::GetDefaultArchitecture() would not match the single architecture in the file specified. This caused running the test suite remotely with lldb-platform to fail many many tests due to the bad target. - It would specify the currently selected platform which might not work for the specified platform All other SBDebugger::CreateTarget calls do not assume an architecture or platform and if they aren't specified, they don't auto select the wrong one for you. With this fix, SBTarget SBDebugger::CreateTarget (const char *filename) now behaves like the other SBDebugger::CreateTarget() variants. llvm-svn: 221908
* Introduce the notion of "type summary options" as flags that can be passed ↵Enrico Granata2014-11-062-0/+120
| | | | | | | | | | | | | 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
* Fixed SBTarget::ReadMemory() to work correctly and the TestTargetAPI.py test ↵Greg Clayton2014-11-041-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | case that was reading target memory in TargetAPITestCase.test_read_memory_with_dsym and TargetAPITestCase.test_read_memory_with_dwarf. The problem was that SBTarget::ReadMemory() was making a new section offset lldb_private::Address by doing: size_t SBTarget::ReadMemory (const SBAddress addr, void *buf, size_t size, lldb::SBError &error) { ... lldb_private::Address addr_priv(addr.GetFileAddress(), NULL); bytes_read = target_sp->ReadMemory(addr_priv, false, buf, size, err_priv); This is wrong. If you get the file addresss from the "addr" argument and try to read memory using that, it will think the file address is a load address and it will try to resolve it accordingly. This will work fine if your executable is loaded at the same address (no slide), but it won't work if there is a slide. The fix is to just pass along the "addr.ref()" instead of making a new addr_priv as this will pass along the lldb_private::Address that is inside the SBAddress (which is what we want), and not always change it into something that becomes a load address (if we are running), or abmigious file address (think address zero when you have 150 shared libraries that have sections that start at zero, which one would you pick). The main reason for passing a section offset address to SBTarget::ReadMemory() is so you _can_ read from the actual section + offset that is specified in the SBAddress. llvm-svn: 221213
* SBAddress currently *may* have an Address object or it may not.Jason Molenda2014-10-311-21/+21
| | | | | | | | | | | | | | | | | | | If it has an Address object, it is assumed to be Valid. Change SBAddress to always have an Address object and check whether it is valid or not in those case. This is fixing a subtle problem where we ended up with a SBAddress with an Address of LLDB_INVALID_ADDRESS could run through a copy constructor and turn into an SBAddress with no Address object being backed (because it wasn't distinguishing between invalid-Address versus no-Address.) The cost of an Address object is not high and this will be an easy mistake for someone else to make; I'm fixing SBAddress so it doesn't come up again. <rdar://problem/18069407> llvm-svn: 221002
* Add a few functions to SBType to handle arrays and typedefs. Fixes ↵Enrico Granata2014-10-281-1/+23
| | | | | | rdar://12675166 llvm-svn: 220824
* Add a feature where a string data formatter can now be partially composed of ↵Enrico Granata2014-10-281-0/+7
| | | | | | | | | | | | | | Python summary functions This works similarly to the {thread/frame/process/target.script:...} feature - you write a summary string, part of which is ${var.script:someFuncName} someFuncName is expected to be declared as def someFuncName(SBValue,otherArgument) - essentially the same as a summary function Since . -> [] are the only allowed separators, and % is used for custom formatting, .script: would not be a legitimate symbol anyway, which makes this non-ambiguous llvm-svn: 220821
* Fix a problem where an SBType was advertising its static type class even ↵Enrico Granata2014-10-231-1/+1
| | | | | | though a dynamic type was available. Solves rdar://18744420 llvm-svn: 220511
* Added functions to the C++ API, for the benefit of non-8-bit byte architectures.Matthew Gardiner2014-10-222-0/+82
| | | | | | | | | | | | 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/+8
| | | | | | more informational content to consumers of the LLDB API than the existing TypeClass. Part of the fix for rdar://18517593 llvm-svn: 220322
* Make the "synchronous" mode actually work without race conditions.Greg Clayton2014-10-213-25/+13
| | | | | | There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be. llvm-svn: 220254
* Remove LLDB_DEFAULT_SHELL #define, and determine this at runtime.Zachary Turner2014-10-201-2/+5
| | | | | | | Differential Revision: http://reviews.llvm.org/D5805 Reviewed by: Greg Clayton llvm-svn: 220217
* This adds a "batch mode" to lldb kinda like the gdb batch mode. It will ↵Jim Ingham2014-10-143-2/+76
| | | | | | | | | | | | | | | | 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/+15
| | | | | | | | | | 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-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
OpenPOWER on IntegriCloud