summaryrefslogtreecommitdiffstats
path: root/lldb/scripts/Python/interface/SBValue.i
Commit message (Collapse)AuthorAgeFilesLines
* Start to share SWIG interface files between languages.Bruce Mitchener2015-04-241-520/+0
| | | | | | | | | | | | | | | | | | | | Summary: Move scripts/Python/interface to scripts/interface so that we can start making iterative improvements towards sharing the interface files between multiple languages (each of which would have their own directory as now). Test Plan: Build and see. Reviewers: zturner, emaste, clayborg Reviewed By: clayborg Subscribers: mjsabby, lldb-commits Differential Revision: http://reviews.llvm.org/D9212 llvm-svn: 235676
* Introduce the notion of "runtime support values"Enrico Granata2015-02-111-0/+3
| | | | | | | | | | | | A runtime support value is a ValueObject whose only purpose is to support some language runtime's operation, but it does not directly provide any user-visible benefit As such, unless the user is working on the runtime support, it is mostly safe for them not to see such a value when debugging It is a language runtime's job to check whether a ValueObject is a support value, and that - in conjunction with a target setting - is used by frame variable and target variable SBFrame::GetVariables gets a new overload with yet another flag to dictate whether to return those support values to the caller - that which defaults to the setting's value rdar://problem/15539930 llvm-svn: 228791
* Add the ability for an SBValue to create a persisted version of itself.Enrico Granata2014-12-081-0/+3
| | | | | | | | | | | | Such a persisted version is equivalent to evaluating the value via the expression evaluator, and holding on to the $n result of the expression, except this API can be used on SBValues that do not obviously come from an expression (e.g. are the result of a memory lookup) Expose this via SBValue::Persist() in our public API layer, and ValueObject::Persist() in the lldb_private layer Includes testcase Fixes rdar://19136664 llvm-svn: 223711
* 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
* Introduce the notion of "type summary options" as flags that can be passed ↵Enrico Granata2014-11-061-0/+3
| | | | | | | | | | | | | 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
* 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
* Fix typos.Bruce Mitchener2014-07-011-3/+3
| | | | llvm-svn: 212132
* Introduce the concept of a "display name" for typesEnrico Granata2014-05-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | 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
* Make sure we expose SetData() through the PythonSean Callanan2013-04-131-0/+3
| | | | | | interface. llvm-svn: 179439
* <rdar://problem/12493007>Greg Clayton2012-10-231-0/+3
| | | | | | | | | | | 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. llvm-svn: 166460
* <rdar://problem/12437442>Enrico Granata2012-10-221-0/+15
| | | | | | | | | | | 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) llvm-svn: 166426
* Add the ability to set timeout & "run all threads" options both from the ↵Jim Ingham2012-10-161-0/+3
| | | | | | | | | | "expr" command and from the SB API's that evaluate expressions. <rdar://problem/12457211> llvm-svn: 166062
* <rdar://problem/12462744> Implement a new SBDeclaration class to wrap an ↵Enrico Granata2012-10-101-0/+3
| | | | | | 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 llvm-svn: 165672
* Added documentation for many of our python properties and also made the ↵Greg Clayton2012-06-291-26/+26
| | | | | | property help show up by declaring the properties correctly. We previosly declared properties into a local "x" variable, what I didn't realize is that the help will use this as the property name for the help output. llvm-svn: 159468
* rdar://problem/11584012Johnny Chen2012-06-041-2/+2
| | | | | | | | | | | 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. llvm-svn: 157964
* <rdar://problem/11239650> Fixing a bug where the SetValueFromCString() ↵Enrico Granata2012-05-081-0/+3
| | | | | | 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 llvm-svn: 156422
* Added a property to get the dynamic type which uses the most permissive way ↵Greg Clayton2012-04-111-2/+8
| | | | | | to get a dynamic type. llvm-svn: 154502
* Synthetic values are now automatically enabled and active by default. ↵Enrico Granata2012-03-271-28/+28
| | | | | | | | | | | | 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 llvm-svn: 153495
* Adding formatters for several useful Objective-C/Cocoa data types. The new ↵Enrico Granata2012-02-171-0/+12
| | | | | | | | | | 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 llvm-svn: 150784
* Expose more convenience functionality in the python classes.Greg Clayton2012-02-031-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lldb.SBValueList now exposes the len() method and also allows item access: lldb.SBValueList[<int>] - where <int> is an integer index into the list, returns a single lldb.SBValue which might be empty if the index is out of range lldb.SBValueList[<str>] - where <str> is the name to look for, returns a list() of lldb.SBValue objects with any matching values (the list might be empty if nothing matches) lldb.SBValueList[<re>] - where <re> is a compiles regular expression, returns a list of lldb.SBValue objects for containing any matches or a empty list if nothing matches lldb.SBFrame now exposes: lldb.SBFrame.variables => SBValueList of all variables that are in scope lldb.SBFrame.vars => see lldb.SBFrame.variables lldb.SBFrame.locals => SBValueList of all variables that are locals in the current frame lldb.SBFrame.arguments => SBValueList of all variables that are arguments in the current frame lldb.SBFrame.args => see lldb.SBFrame.arguments lldb.SBFrame.statics => SBValueList of all static variables lldb.SBFrame.registers => SBValueList of all registers for the current frame lldb.SBFrame.regs => see lldb.SBFrame.registers Combine any of the above properties with the new lldb.SBValueList functionality and now you can do: y = lldb.frame.vars['rect.origin.y'] or vars = lldb.frame.vars for i in range len(vars): print vars[i] Also expose "lldb.SBFrame.var(<str>)" where <str> can be en expression path for any variable or child within the variable. This makes it easier to get a value from the current frame like "rect.origin.y". The resulting value is also not a constant result as expressions will return, but a live value that will continue to track the current value for the variable expression path. lldb.SBValue now exposes: lldb.SBValue.unsigned => unsigned integer for the value lldb.SBValue.signed => a signed integer for the value llvm-svn: 149684
* Added the ability to get the target triple, byte order and address byte sizeGreg Clayton2012-01-291-0/+76
| | | | | | | from the SBTarget and SBModule interfaces. Also added many python properties for easier access to many things from many SB objects. llvm-svn: 149191
* Add needed Clear methods.Jim Ingham2011-12-191-0/+3
| | | | | | <rdar://problem/10596340> llvm-svn: 146902
* Add SBValue::GetDynamicValue and SBValue::GetStaticValue API's.Jim Ingham2011-12-081-0/+9
| | | | | | <rdar://problem/10545069> llvm-svn: 146173
* SBValue::Watch() and SBValue::WatchPointee() are now the official API for ↵Johnny Chen2011-10-141-0/+8
| | | | | | | | | | | | | | | | | | 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. llvm-svn: 141925
* Cleaned up the SBWatchpoint public API.Greg Clayton2011-10-131-0/+6
| | | | llvm-svn: 141876
* Added the ability to introspect types thourgh the public SBType interface.Greg Clayton2011-09-091-7/+7
| | | | | | | | 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. llvm-svn: 139428
* Redesign of the interaction between Python and frozen objects:Enrico Granata2011-09-061-1/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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 llvm-svn: 139160
* APIs to GetValueAsSigned/Unsigned() in SBValue now also accept an SBError ↵Enrico Granata2011-08-041-1/+7
| | | | | | | | | 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 llvm-svn: 136861
* Cleaned up the SBType.h file to not include internal headers and reorganizedGreg Clayton2011-08-031-32/+6
| | | | | | | | | | | | | | | | | | 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) llvm-svn: 136829
* Public API changes:Enrico Granata2011-07-291-1/+30
| | | | | | | | | | | | | | | | | | | | | - 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 llvm-svn: 136504
* Add deprecation docstrings for some APIs which take an SBFrame - SBValues ↵Johnny Chen2011-07-271-7/+18
| | | | | | know their own frames. llvm-svn: 136194
* Add cross references between the docstrings for regular SBValue iteration:Johnny Chen2011-07-251-1/+5
| | | | | | | | | | | | for child in value: # do something with the child value and SBValue.linked_list_iter(): for task in task_head.linked_list_iter('next', eol_test): # visit each item in the linked list llvm-svn: 136015
* Add SWIG Python interface files for SBProcess, SBThread, and SBFrame.Johnny Chen2011-07-181-3/+2
| | | | llvm-svn: 135419
* Fix header documentations.Johnny Chen2011-07-181-1/+1
| | | | llvm-svn: 135417
* Add two new interface files SBValue.i and SBValueList.i, instead of directly ↵Johnny Chen2011-07-181-0/+265
swigging the header files. llvm-svn: 135416
OpenPOWER on IntegriCloud