bef2dde1407f2b7b7cf36739d23439c8f1dd0fc4 |
|
15-May-2013 |
Jim Ingham <jingham@apple.com> |
Change the mechanism around SBValue::GetSP() so that it always requires the target API lock AND the process StopLocker (if there is a process) before it will hand out SBValues. We were doing this in an ad hoc fashion previously, and then playing whack-a-mole whenever we found a place where we should have been doing this but weren't. Really, it doesn't make sense to be poking at SBValues when the target is running, the dynamic and synthetic values can't really be computed, and the underlying memory may be incoherent. <rdar://problem/13819378> Sometimes when stepping fast, my inferior is killed by debugserver git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181863 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
bf26ea6ffa9426b8f23c78aa8cf18b809beb364c |
|
23-Apr-2013 |
Enrico Granata <egranata@apple.com> |
Daniel Malea reported seeing warnings for the use of anonymous namespaces in our public API. Removing these namespace { ... } declarations (but still keeping the helper *Impl objects outside of namespace lldb proper) git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@180067 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
102b2c2681c9a830afe25bfea35557421905e42c |
|
19-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179805 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
ab8e00e51475b9148626bfdf99549b7ffc3d046d |
|
13-Apr-2013 |
Sean Callanan <scallanan@apple.com> |
Added a SetData() method to ValueObject. This lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179437 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
19b646725e7d6bebda787fa3cb55ff223a00d907 |
|
04-Jan-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/12928282> Added SBTarget::EvaluateExpression() so expressions can be evaluated without needing a process. Also fixed many functions that deal with clang AST types to be able to properly handle the clang::Type::Elaborated types ("struct foo", "class bar"). git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@171476 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
eeabe815b3d36b69b4666fbbce78a4bf950de3cc |
|
01-Nov-2012 |
Greg Clayton <gclayton@apple.com> |
Get rid of hack by making the actual call public. This was causing the lldb-platform to not be able to link. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@167253 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
54037b1488e3344575714d8358728e042fa801c7 |
|
23-Oct-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/12493007> Added a new API call to help efficiently determine if a SBValue could have children: bool SBValue::MightHaveChildren (); This is inteneded to be used bui GUI programs that need to show if a SBValue needs a disclosure triangle when displaying a hierarchical type in a tree view without having to complete the type (by calling SBValue::GetNumChildren()) as completing the type is expensive. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166460 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
3d656c729a1ed0abad4e5a2d76f6e8a6904f66aa |
|
22-Oct-2012 |
Enrico Granata <egranata@apple.com> |
<rdar://problem/12437442> Given our implementation of ValueObjects we could have a scenario where a ValueObject has a dynamic type of Foo* at one point, and then its dynamic type changes to Bar* If Bar* has synthetic children enabled, by the time we figure that out, our public API is already vending SBValues wrapping a DynamicVO, instead of a SyntheticVO and there was no trivial way for us to change the SP inside an SBValue on the fly This checkin reimplements SBValue in terms of a wrapper, ValueImpl, that allows this substitutions on-the-fly by overriding GetSP() to do The Right Thing (TM) As an additional bonus, GetNonSyntheticValue() now works, and we can get rid of the ForceDisableSyntheticChildren idiom in ScriptInterpreterPython Lastly, this checkin makes sure the synthetic VOs get the correct m_value and m_data from their parents (prevented summaries from working in some cases) git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166426 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
47beabb1386be44e3f90dbc30a0b22c23b93a4dc |
|
16-Oct-2012 |
Jim Ingham <jingham@apple.com> |
Add the ability to set timeout & "run all threads" options both from the "expr" command and from the SB API's that evaluate expressions. <rdar://problem/12457211> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166062 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
49306144bb37f0b3423d992f17cdcc24703374b4 |
|
11-Oct-2012 |
Enrico Granata <egranata@apple.com> |
<rdar://problem/12462744> Implement a new SBDeclaration class to wrap an lldb_private::Declaration - make a GetDeclaration() API on SBValue to return a declaration. This will only work for vroot variables as they are they only objects for which we currently provide a valid Declaration git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@165672 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
a17a81a1a9ff6b8d87c4a1e47dd874f6ea8a4f1d |
|
12-Sep-2012 |
Jim Ingham <jingham@apple.com> |
Start at getting "thread return" working. Doesn't work yet. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@163670 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
8a5ce77ad5356af485a119186fc2ad536d21149b |
|
05-Jun-2012 |
Johnny Chen <johnny.chen@apple.com> |
Cannot break the existing API client of SBValue::Watch(bool resolve_location, bool read, bool write). Leave this method in the codebase for a while. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@157967 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
3f883496e92fce5011f6bf585af3ac6d1cddb64f |
|
05-Jun-2012 |
Johnny Chen <johnny.chen@apple.com> |
rdar://problem/11584012 Refactorings of watchpoint creation APIs so that SBTarget::WatchAddress(), SBValue::Watch(), and SBValue::WatchPointee() now take an additional 'SBError &error' parameter (at the end) to contain the reason if there is some failure in the operation. Update 'watchpoint set variable/expression' commands to take advantage of that. Update existing test cases to reflect the API change and add test cases to verify that the SBError mechanism works for SBTarget::WatchAddress() by passing an invalid watch_size. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@157964 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
651cbe2e3f6efb8bd579a5007c2d2f90f0ab7633 |
|
08-May-2012 |
Enrico Granata <egranata@apple.com> |
<rdar://problem/11239650> Fixing a bug where the SetValueFromCString() method failed to operate on dynamic values. The fix consists in making the set operation fall through to the parent. We only actually allow this if the dynamic value is at a 0-offset from the parent, or the new value is 0. Other scenarios would need agreement on the actual meaning of the set operation (do we keep offsetting? do we just assume the user knows what they are doing?) so we prevent them, and let the expression parser deal with the complexity git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@156422 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
d9488c8ba7df755686f38a91bd3f9a9270a5a128 |
|
08-May-2012 |
Enrico Granata <egranata@apple.com> |
Removing spurious friend declaration git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@156398 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
4758a3ced524198d2cf9c50bab9b088adcbda9cb |
|
08-May-2012 |
Enrico Granata <egranata@apple.com> |
First part of a fix to make GetNonSyntheticValue() work correctly git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@156397 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
dba1de8d585f27601162f674d30ab71d9c83ccde |
|
27-Mar-2012 |
Enrico Granata <egranata@apple.com> |
Synthetic values are now automatically enabled and active by default. SBValue is set up to always wrap a synthetic value when one is available. A new setting enable-synthetic-value is provided on the target to disable this behavior. There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic. The test suite has been changed accordingly. Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@153495 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
c48ca82920bd333c7ccb6ec0e579207add130296 |
|
21-Feb-2012 |
Jason Molenda <jmolenda@apple.com> |
Patch Enrico's changes from r150558 on 2012-02-14 to build even if Python is not available (LLDB_DISABLE_PYTHON is defined). Change build-swig-Python.sh to emit an empty LLDBPythonWrap.cpp file if this build is LLDB_DISABLE_PYTHON. Change the "Copy to Xcode.app" shell script phase in the lldb.xcodeproj to only do this copying for Mac native builds. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151035 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
d760907c1d42726fa0c8c48efa28385ed339bb94 |
|
17-Feb-2012 |
Enrico Granata <granata.enrico@gmail.com> |
Adding formatters for several useful Objective-C/Cocoa data types. The new categories are not enabled at startup, but can be manually activated if desired. Adding new API calls to SBValue to be able to retrieve the associated formatters Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed) Test cases added for the above git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150784 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
7dd5c51fbab8384b18f20ecc125f9a1bb3c9bcb2 |
|
06-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
Removed all of the "#ifndef SWIG" from the SB header files since we are using interface (.i) files for each class. Changed the FindFunction class from: uint32_t SBTarget::FindFunctions (const char *name, uint32_t name_type_mask, bool append, lldb::SBSymbolContextList& sc_list) uint32_t SBModule::FindFunctions (const char *name, uint32_t name_type_mask, bool append, lldb::SBSymbolContextList& sc_list) To: lldb::SBSymbolContextList SBTarget::FindFunctions (const char *name, uint32_t name_type_mask = lldb::eFunctionNameTypeAny); lldb::SBSymbolContextList SBModule::FindFunctions (const char *name, uint32_t name_type_mask = lldb::eFunctionNameTypeAny); This makes the API easier to use from python. Also added the ability to append a SBSymbolContext or a SBSymbolContextList to a SBSymbolContextList. Exposed properties for lldb.SBSymbolContextList in python: lldb.SBSymbolContextList.modules => list() or all lldb.SBModule objects in the list lldb.SBSymbolContextList.compile_units => list() or all lldb.SBCompileUnits objects in the list lldb.SBSymbolContextList.functions => list() or all lldb.SBFunction objects in the list lldb.SBSymbolContextList.blocks => list() or all lldb.SBBlock objects in the list lldb.SBSymbolContextList.line_entries => list() or all lldb.SBLineEntry objects in the list lldb.SBSymbolContextList.symbols => list() or all lldb.SBSymbol objects in the list This allows a call to the SBTarget::FindFunctions(...) and SBModule::FindFunctions(...) and then the result can be used to extract the desired information: sc_list = lldb.target.FindFunctions("erase") for function in sc_list.functions: print function for symbol in sc_list.symbols: print symbol Exposed properties for the lldb.SBSymbolContext objects in python: lldb.SBSymbolContext.module => lldb.SBModule lldb.SBSymbolContext.compile_unit => lldb.SBCompileUnit lldb.SBSymbolContext.function => lldb.SBFunction lldb.SBSymbolContext.block => lldb.SBBlock lldb.SBSymbolContext.line_entry => lldb.SBLineEntry lldb.SBSymbolContext.symbol => lldb.SBSymbol Exposed properties for the lldb.SBBlock objects in python: lldb.SBBlock.parent => lldb.SBBlock for the parent block that contains lldb.SBBlock.sibling => lldb.SBBlock for the sibling block to the current block lldb.SBBlock.first_child => lldb.SBBlock for the first child block to the current block lldb.SBBlock.call_site => for inline functions, return a lldb.declaration object that gives the call site file, line and column lldb.SBBlock.name => for inline functions this is the name of the inline function that this block represents lldb.SBBlock.inlined_block => returns the inlined function block that contains this block (might return itself if the current block is an inlined block) lldb.SBBlock.range[int] => access the address ranges for a block by index, a list() with start and end address is returned lldb.SBBlock.ranges => an array or all address ranges for this block lldb.SBBlock.num_ranges => the number of address ranges for this blcok SBFunction objects can now get the SBType and the SBBlock that represents the top scope of the function. SBBlock objects can now get the variable list from the current block. The value list returned allows varaibles to be viewed prior with no process if code wants to check the variables in a function. There are two ways to get a variable list from a SBBlock: lldb::SBValueList SBBlock::GetVariables (lldb::SBFrame& frame, bool arguments, bool locals, bool statics, lldb::DynamicValueType use_dynamic); lldb::SBValueList SBBlock::GetVariables (lldb::SBTarget& target, bool arguments, bool locals, bool statics); When a SBFrame is used, the values returned will be locked down to the frame and the values will be evaluated in the context of that frame. When a SBTarget is used, global an static variables can be viewed without a running process. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149853 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
0a19a1b9c25117854f226256805239d95153ed2d |
|
04-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
Convert all python objects in our API to use overload the __str__ method instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149743 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
e0bd571a8050da2b3462c35c9f209cbc9755c750 |
|
19-Dec-2011 |
Jim Ingham <jingham@apple.com> |
Add needed Clear methods. <rdar://problem/10596340> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@146902 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
1b42575189379cb0c1441f74a48127e9ab7335e3 |
|
08-Dec-2011 |
Jim Ingham <jingham@apple.com> |
Add SBValue::GetDynamicValue and SBValue::GetStaticValue API's. <rdar://problem/10545069> git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@146173 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
ecd4feb5111432d2878e95461220c720cb2d24c8 |
|
14-Oct-2011 |
Johnny Chen <johnny.chen@apple.com> |
SBValue::Watch() and SBValue::WatchPointee() are now the official API for creating a watchpoint for either the variable encapsulated by SBValue (Watch) or the pointee encapsulated by SBValue (WatchPointee). Removed SBFrame::WatchValue() and SBFrame::WatchLocation() API as a result of that. Modified the watchpoint related test suite to reflect the change. Plus replacing WatchpointLocation with Watchpoint throughout the code base. There are still cleanups to be dome. This patch passes the whole test suite. Check it in so that we aggressively catch regressions. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@141925 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
1fa6b3d6c83955fe06c63d3a4025f2c0ec431d68 |
|
13-Oct-2011 |
Greg Clayton <gclayton@apple.com> |
Cleaned up the SBWatchpoint public API. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@141876 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
cc7de484073d40dc115e4f1a8271f016718a3714 |
|
16-Sep-2011 |
Johnny Chen <johnny.chen@apple.com> |
Untabify and fix indentation. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139867 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
d68e089f8353eaf845c3559dac6d47b32830974f |
|
10-Sep-2011 |
Greg Clayton <gclayton@apple.com> |
Added the ability to introspect types thourgh the public SBType interface. Fixed up many API calls to not be "const" as const doesn't mean anything to most of our lldb::SB objects since they contain a shared pointer, auto_ptr, or pointer to the types which circumvent the constness anyway. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139428 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
915448044bac6fdac22a33cc46697dcb771a8df2 |
|
06-Sep-2011 |
Enrico Granata <granata.enrico@gmail.com> |
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139160 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
c92eb4004a354b0ea085b610b2ba991e575b1c32 |
|
04-Aug-2011 |
Enrico Granata <granata.enrico@gmail.com> |
APIs to GetValueAsSigned/Unsigned() in SBValue now also accept an SBError parameter to give more info about any problem The synthetic children providers now use the new (safer) APIs to get the values of objects As a side effect, fixed an issue in ValueObject where ResolveValue() was not always updating the value before reading it git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@136861 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
0fb0bcc9d4e951145e1b8c783652224c09b23af4 |
|
04-Aug-2011 |
Greg Clayton <gclayton@apple.com> |
Cleaned up the SBType.h file to not include internal headers and reorganized the SBType implementation classes. Fixed LLDB core and the test suite to not use deprecated SBValue APIs. Added a few new APIs to SBValue: int64_t SBValue::GetValueAsSigned(int64_t fail_value=0); uint64_t SBValue::GetValueAsUnsigned(uint64_t fail_value=0) git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@136829 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
979e20d127335143ffc89c2e37ec3a8b717ff22d |
|
29-Jul-2011 |
Enrico Granata <granata.enrico@gmail.com> |
Public API changes: - Completely new implementation of SBType - Various enhancements in several other classes Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>: - these return the actual elements into the container as the children of the container - basic template name parsing that works (hopefully) on both Clang and GCC - find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth New summary string token ${svar : - the syntax is just the same as in ${var but this new token lets you read the values coming from the synthetic children provider instead of the actual children - Python providers above provide a synthetic child len that returns the number of elements into the container Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB Several other fixes, including: - inverted the order of arguments in the ClangASTType constructor - EvaluationPoint now only returns SharedPointer's to Target and Process - the help text for several type subcommands now correctly indicates argument-less options as such git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@136504 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
9ae7cef26612773c6b3422834cec83f0fbb2cf8c |
|
24-Jul-2011 |
Enrico Granata <granata.enrico@gmail.com> |
Python synthetic children: - you can now define a Python class as a synthetic children producer for a type the class must adhere to this "interface": def __init__(self, valobj, dict): def get_child_at_index(self, index): def get_child_index(self, name): then using type synth add -l className typeName (e.g. type synth add -l fooSynthProvider foo) (This is still WIP with lots to be added) A small test case is available also as reference git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135865 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
854a1ba617fded6eb054b3f93b3299d0a7173ca1 |
|
18-Jul-2011 |
Johnny Chen <johnny.chen@apple.com> |
Add two new interface files SBValue.i and SBValueList.i, instead of directly swigging the header files. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135416 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
533ed2fd6d3763654cd35cdc2379e1bf1049e0dd |
|
15-Jul-2011 |
Johnny Chen <johnny.chen@apple.com> |
Add some more docstrings for SBCompileUnit and SBBreakpoint, plus incorporate the doxgen doc block of SBValue::GetChildAtIndex(uint32_t idx, lldb::DynamicValueType use_dynamic, bool can_create_synthetic); into the SBValue docstrings. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135295 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
8f64c47120c81728aac0ab0d66097c9a92284f6f |
|
15-Jul-2011 |
Greg Clayton <gclayton@apple.com> |
Added the ability to get synthetic child values from SBValue objects that represent pointers and arrays by adding an extra parameter to the SBValue SBValue::GetChildAtIndex (uint32_t idx, DynamicValueType use_dynamic, bool can_create_synthetic); The new "can_create_synthetic" will allow you to create child values that aren't actually a part of the original type. So if you code like: int *foo_ptr = ... And you have a SBValue that contains the value for "foo_ptr": SBValue foo_value = ... You can now get the "foo_ptr[12]" item by doing this: v = foo_value.GetChiltAtIndex (12, lldb.eNoDynamicValues, True); Normall the "foo_value" would only have one child value (an integer), but we can create "synthetic" child values by treating the pointer as an array. Likewise if you have code like: int array[2]; array_value = .... v = array_value.GetChiltAtIndex (0); // Success, v will be valid v = array_value.GetChiltAtIndex (1); // Success, v will be valid v = array_value.GetChiltAtIndex (2); // Fail, v won't be valid, "2" is not a valid zero based index in "array" But if you use the ability to create synthetic children: v = array_value.GetChiltAtIndex (0, lldb.eNoDynamicValues, True); // Success, v will be valid v = array_value.GetChiltAtIndex (1, lldb.eNoDynamicValues, True); // Success, v will be valid v = array_value.GetChiltAtIndex (2, lldb.eNoDynamicValues, True); // Success, v will be valid git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135292 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
f7a9b14c2c02d2fa9fad586c19f29d77533fcc09 |
|
15-Jul-2011 |
Enrico Granata <granata.enrico@gmail.com> |
Python summary strings: - you can use a Python script to write a summary string for data-types, in one of three ways: -P option and typing the script a line at a time -s option and passing a one-line Python script -F option and passing the name of a Python function these options all work for the "type summary add" command your Python code (if provided through -P or -s) is wrapped in a function that accepts two parameters: valobj (a ValueObject) and dict (an LLDB internal dictionary object). if you use -F and give a function name, you're expected to define the function on your own and with the right prototype. your function, however defined, must return a Python string - test case for the Python summary feature - a few quirks: Python summaries cannot have names, and cannot use regex as type names both issues will be fixed ASAP major redesign of type summary code: - type summary working with strings and type summary working with Python code are two classes, with a common base class SummaryFormat - SummaryFormat classes now are able to actively format objects rather than just aggregating data - cleaner code to print descriptions for summaries the public API now exports a method to easily navigate a ValueObject hierarchy New InputReaderEZ and PriorityPointerPair classes Several minor fixes and improvements git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135238 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
e3a83d21d6f4fd813446fc7471c739507bbe11b5 |
|
15-Jul-2011 |
Johnny Chen <johnny.chen@apple.com> |
Add usage docstring to SBValue.h, and minor update of docstrings for SBValueList.h. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135230 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
968958c31c42224cfd5eb4ba0cf6fe0157ab375c |
|
07-Jul-2011 |
Johnny Chen <johnny.chen@apple.com> |
Add SBValue::GetID() member method call API. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@134636 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
a0d0a7cbd773ded4ced8d5065f993b6e0feb8dfe |
|
01-Jul-2011 |
Johnny Chen <johnny.chen@apple.com> |
Add docstrings for some API classes and auto-generates docstrings for the methods of them. A few of the auto-generated method docstrings don't look right, and may need to be fixed by either overwriting the auto-gened docstrings or some post-processing steps. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@134246 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
10de7d1db3ec782ea2ccda1f39c0a40b9c301594 |
|
04-May-2011 |
Jim Ingham <jingham@apple.com> |
Change "frame var" over to using OptionGroups (and thus the OptionGroupVariableObjectDisplay). Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target, and dynamic with running target. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@130832 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
e41494a9092e15192012a5e0a8a1ffd66c70b8bb |
|
16-Apr-2011 |
Jim Ingham <jingham@apple.com> |
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@129623 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
fa3a16a2ea380ef38388ebe323817bd1b32c20cd |
|
31-Mar-2011 |
Jim Ingham <jingham@apple.com> |
Convert ValueObject to explicitly maintain the Execution Context in which they were created, and then use that when they update themselves. That means all the ValueObject evaluate me type functions that used to require a Frame object now do not. I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128593 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
b01000fd063629facd45044f137446fb748ee179 |
|
17-Jan-2011 |
Greg Clayton <gclayton@apple.com> |
A few of the issue I have been trying to track down and fix have been due to the way LLDB lazily gets complete definitions for types within the debug info. When we run across a class/struct/union definition in the DWARF, we will only parse the full definition if we need to. This works fine for top level types that are assigned directly to variables and arguments, but when we have a variable with a class, lets say "A" for this example, that has a member: "B *m_b". Initially we don't need to hunt down a definition for this class unless we are ever asked to do something with it ("expr m_b->getDecl()" for example). With my previous approach to lazy type completion, we would be able to take a "A *a" and get a complete type for it, but we wouldn't be able to then do an "a->m_b->getDecl()" unless we always expanded all types within a class prior to handing out the type. Expanding everything is very costly and it would be great if there were a better way. A few months ago I worked with the llvm/clang folks to have the ExternalASTSource class be able to complete classes if there weren't completed yet: class ExternalASTSource { .... virtual void CompleteType (clang::TagDecl *Tag); virtual void CompleteType (clang::ObjCInterfaceDecl *Class); }; This was great, because we can now have the class that is producing the AST (SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources and the object that creates the forward declaration types can now also complete them anywhere within the clang type system. This patch makes a few major changes: - lldb_private::Module classes now own the AST context. Previously the TypeList objects did. - The DWARF parsers now sign up as an external AST sources so they can complete types. - All of the pure clang type system wrapper code we have in LLDB (ClangASTContext, ClangASTType, and more) can now be iterating through children of any type, and if a class/union/struct type (clang::RecordType or ObjC interface) is found that is incomplete, we can ask the AST to get the definition. - The SymbolFileDWARFDebugMap class now will create and use a single AST that all child SymbolFileDWARF classes will share (much like what happens when we have a complete linked DWARF for an executable). We will need to modify some of the ClangUserExpression code to take more advantage of this completion ability in the near future. Meanwhile we should be better off now that we can be accessing any children of variables through pointers and always be able to resolve the clang type if needed. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123613 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
e179a5840a49167964ca768a13c252c58c9cffcc |
|
05-Jan-2011 |
Greg Clayton <gclayton@apple.com> |
Added the ability to get an set the desired format for SBValue objects. Fixed the display of complex numbers in lldb_private::DataExtractor::Dump(...) and also fixed other edge display cases in lldb_private::ClangASTType::DumpTypeValue(...). git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@122895 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
bdcda468276dc9ab6bf648fc8cc07f3faad91526 |
|
20-Dec-2010 |
Greg Clayton <gclayton@apple.com> |
The LLDB API (lldb::SB*) is now thread safe! git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@122262 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
538eb82a89a68dbc57251915080bd5152b333978 |
|
06-Nov-2010 |
Greg Clayton <gclayton@apple.com> |
Added copy constructors and assignment operators to all lldb::SB* classes so we don't end up with weak exports with some compilers. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118312 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
49ce682dfa7993d31206cea19ce7006cd3f3077e |
|
31-Oct-2010 |
Greg Clayton <gclayton@apple.com> |
Cleaned up the API logging a lot more to reduce redundant information and keep the file size a bit smaller. Exposed SBValue::GetExpressionPath() so SBValue users can get an expression path for their values. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@117851 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
f3d0b0c8081691128626eb496fdfcbf8ae54c1de |
|
27-Oct-2010 |
Greg Clayton <gclayton@apple.com> |
Updated the lldb_private::Flags class to have better method names and made all of the calls inlined in the header file for better performance. Fixed the summary for C string types (array of chars (with any combo if modifiers), and pointers to chars) work in all cases. Fixed an issue where a forward declaration to a clang type could cause itself to resolve itself more than once if, during the resolving of the type itself it caused something to try and resolve itself again. We now remove the clang type from the forward declaration map in the DWARF parser when we start to resolve it and avoid this additional call. This should stop any duplicate members from appearing and throwing all the alignment of structs, unions and classes. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@117437 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
c5f728c81b4896cfbbc87ed1daedf42ba2c0ee63 |
|
07-Oct-2010 |
Greg Clayton <gclayton@apple.com> |
Expose the error contained within an SBValue. Move anything that creates a new process into SBTarget. Marked some functions as deprecated. I will remove them after our new API changes make it through a build cycle. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@115854 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
e49ec18f1868168c8927ae30a379db176ca8cce3 |
|
23-Sep-2010 |
Caroline Tice <ctice@apple.com> |
Remove all the __repr__ methods from the API/*.h files, and put them into python-extensions.swig, which gets included into lldb.swig, and adds them back into the classes when swig generates it's C++ file. This keeps the Python stuff out of the general API classes. Also fixed a small bug in the copy constructor for SBSymbolContext. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114602 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
98f930f429160f9777f626c3ac6aa609f4e965d2 |
|
20-Sep-2010 |
Caroline Tice <ctice@apple.com> |
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114321 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
dfc91c368886f961b5cac95efc9adfe9be05cf73 |
|
15-Sep-2010 |
Caroline Tice <ctice@apple.com> |
Remove unnecessary/inappropriate output-printing functions from the API. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113993 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
4ae519666628cca07c194bf677163009cc2e5a8b |
|
11-Sep-2010 |
Jim Ingham <jingham@apple.com> |
Move the "Object Description" into the ValueObject, and the add an API to SBValue to access it. For now this is just the result of ObjC NSPrintForDebugger, but could be extended. Also store the results of the ObjC Object Printer in a Stream, not a ConstString. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113660 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
17dae081d7b88d24a7af6b07c10fc5981f81e2a9 |
|
02-Sep-2010 |
Greg Clayton <gclayton@apple.com> |
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112800 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
c833295baeec641086f536e78050388af36784f8 |
|
26-Aug-2010 |
Jim Ingham <jingham@apple.com> |
Change "Current" as in GetCurrentThread, GetCurrentStackFrame, etc, to "Selected" i.e. GetSelectedThread. Selected makes more sense, since these are set by some user action (a selection). I didn't change "CurrentProcess" since this is always controlled by the target, and a given target can only have one process, so it really can't be selected. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112221 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
63094e0bb161580564954dee512955c1c79d3476 |
|
23-Jun-2010 |
Greg Clayton <gclayton@apple.com> |
Very large changes that were needed in order to allow multiple connections to the debugger from GUI windows. Previously there was one global debugger instance that could be accessed that had its own command interpreter and current state (current target/process/thread/frame). When a GUI debugger was attached, if it opened more than one window that each had a console window, there were issues where the last one to setup the global debugger object won and got control of the debugger. To avoid this we now create instances of the lldb_private::Debugger that each has its own state: - target list for targets the debugger instance owns - current process/thread/frame - its own command interpreter - its own input, output and error file handles to avoid conflicts - its own input reader stack So now clients should call: SBDebugger::Initialize(); // (static function) SBDebugger debugger (SBDebugger::Create()); // Use which ever file handles you wish debugger.SetErrorFileHandle (stderr, false); debugger.SetOutputFileHandle (stdout, false); debugger.SetInputFileHandle (stdin, true); // main loop SBDebugger::Terminate(); // (static function) SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to ensure nothing gets destroyed too early when multiple clients might be attached. Cleaned up the command interpreter and the CommandObject and all subclasses to take more appropriate arguments. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@106615 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
7884ab842f7f0be6c583eac2904f5763706816bc |
|
12-Jun-2010 |
Eli Friedman <eli.friedman@gmail.com> |
Add missing includes. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105897 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
87c871847dba627a07cf6f4ac8cfb4d6722eccb5 |
|
09-Jun-2010 |
Eli Friedman <eli.friedman@gmail.com> |
Misc warning/error fixes. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105713 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
5f81547fd786584b10999c087528b323b5945896 |
|
09-Jun-2010 |
Eli Friedman <eli.friedman@gmail.com> |
Fix include lines to use more conventional paths, part 1. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105688 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|
24943d2ee8bfaa7cf5893e4709143924157a5c1e |
|
08-Jun-2010 |
Chris Lattner <sabre@nondot.org> |
Initial checkin of lldb code from internal Apple repo. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105619 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/API/SBValue.h
|