summaryrefslogtreecommitdiffstats
path: root/lldb/source/API/SBValue.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-231-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]] This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information. This is the command I ran and I to fix and format the code base: ``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ``` NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow. NOTE: I know this is a rather large commit but it is a nobrainer in most parts. Reviewers: martong, espindola, shafik, #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D61847 llvm-svn: 361484
* [Reproducers] Capture return values of functions returning by ptr/refJonas Devlieghere2019-04-031-1/+1
| | | | | | | | | | | | | | | For some reason I had convinced myself that functions returning by pointer or reference do not require recording their result. However, after further considering I don't see how that could work, at least not with the current implementation. Interestingly enough, the reproducer instrumentation already (mostly) accounts for this, though the lldb-instr tool did not. This patch adds the missing macros and updates the lldb-instr tool. Differential revision: https://reviews.llvm.org/D60178 llvm-svn: 357639
* [lldb] [Reproducer] Move SBRegistry registration into declaring filesMichal Gorny2019-03-191-0/+127
| | | | | | | | | | | | Move SBRegistry method registrations from SBReproducer.cpp into files declaring the individual APIs, in order to reduce the memory consumption during build and improve maintainability. The current humongous SBRegistry constructor exhausts all memory on a NetBSD system with 4G RAM + 4G swap, therefore making it impossible to build LLDB. Differential Revision: https://reviews.llvm.org/D59427 llvm-svn: 356481
* [API] Remove unneded LLDB_DISABLE_PYTHON markers.Davide Italiano2019-03-181-2/+0
| | | | llvm-svn: 356401
* Add "operator bool" to SB APIsPavel Labath2019-03-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: Our python version of the SB API has (the python equivalent of) operator bool, but the C++ version doesn't. This is because our python operators are added by modify-python-lldb.py, which performs postprocessing on the swig-generated interface files. In this patch, I add the "operator bool" to all SB classes which have an IsValid method (which is the same logic used by modify-python-lldb.py). This way, we make the two interfaces more constent, and it allows us to rely on swig's automatic syntesis of python __nonzero__ methods instead of doing manual fixups. Reviewers: zturner, jingham, clayborg, jfb, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58792 llvm-svn: 355824
* [SBAPI] Log from record macroJonas Devlieghere2019-03-071-356/+11
| | | | | | | | | | | | | | | | The current record macros already log the function being called. This patch extends the macros to also log their input arguments and removes explicit logging from the SB API. This might degrade the amount of information in some cases (because of smarter casts or efforts to log return values). However I think this is outweighed by the increased coverage and consistency. Furthermore, using the reproducer infrastructure, diagnosing bugs in the API layer should become much easier compared to relying on log messages. Differential revision: https://reviews.llvm.org/D59101 llvm-svn: 355649
* [Reproducers] Add SBReproducer macrosJonas Devlieghere2019-03-061-55/+282
| | | | | | | | | | This patch adds the SBReproducer macros needed to capture and reply the corresponding calls. This patch was generated by running the lldb-instr tool on the API source files. Differential revision: https://reviews.llvm.org/D57475 llvm-svn: 355459
* Use std::make_shared in LLDB (NFC)Jonas Devlieghere2019-02-111-1/+3
| | | | | | | | | | | Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 llvm-svn: 353764
* [Expressions] Add support of expressions evaluation in some object's contextAleksandr Urakov2019-02-051-0/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds support of expression evaluation in a context of some object. Consider the following example: ``` struct S { int a = 11; int b = 12; }; int main() { S s; int a = 1; int b = 2; // We have stopped here return 0; } ``` This patch allows to do something like that: ``` lldb.frame.FindVariable("s").EvaluateExpression("a + b") ``` and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be used (not locals `a` and `b`). This is achieved by replacing of `this` type and object for the expression. This has some limitations: an expression can be evaluated only for values located in the debuggee process memory (they must have an address of `eAddressTypeLoad` type). Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille Reviewed By: jingham Subscribers: abidh, lldb-commits, leonid.mashinskiy Tags: #lldb Differential Revision: https://reviews.llvm.org/D55318 llvm-svn: 353149
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Simplify Boolean expressionsJonas Devlieghere2018-12-151-4/+1
| | | | | | | | | | | This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command: run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD Differential revision: https://reviews.llvm.org/D55584 llvm-svn: 349215
* Move RegisterValue,Scalar,State from Core to UtilityPavel Labath2018-08-071-1/+1
| | | | | | | | | | | | | These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-25/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
* Rename Error -> Status.Zachary Turner2017-05-121-8/+8
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner2017-03-041-1/+1
| | | | llvm-svn: 296943
* Move Log from Core -> Utility.Zachary Turner2017-03-031-1/+1
| | | | | | | | | All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
* Move classes from Core -> Utility.Zachary Turner2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-1744/+1438
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Because of our lifetime rules w.r.t. ValueObjects and ClusterManagers, ↵Enrico Granata2016-07-061-0/+19
| | | | | | | | | | | | | | | | synthetic children caching is a tricky area: - if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop; - but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval) Fixes rdar://26480007 llvm-svn: 274683
* Added support for thread local variables on all Apple OS variants.Greg Clayton2016-07-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We had support that assumed that thread local data for a variable could be determined solely from the module in which the variable exists. While this work for linux, it doesn't work for Apple OSs. The DWARF for thread local variables consists of location opcodes that do something like: DW_OP_const8u (x) DW_OP_form_tls_address or DW_OP_const8u (x) DW_OP_GNU_push_tls_address The "x" is allowed to be anything that is needed to determine the location of the variable. For Linux "x" is the offset within the TLS data for a given executable (ModuleSP in LLDB). For Apple OS variants, it is the file address of the data structure that contains a pthread key that can be used with pthread_getspecific() and the offset needed. This fix passes the "x" along to the thread: virtual lldb::addr_t lldb_private::Thread::GetThreadLocalData(const lldb::ModuleSP module, lldb::addr_t tls_file_addr); Then this is passed along to the DynamicLoader::GetThreadLocalData(): virtual lldb::addr_t lldb_private::DynamicLoader::GetThreadLocalData(const lldb::ModuleSP module, const lldb::ThreadSP thread, lldb::addr_t tls_file_addr); This allows each DynamicLoader plug-in do the right thing for the current OS. The DynamicLoaderMacOSXDYLD was modified to be able to grab the pthread key from the data structure that is in memory and call "void *pthread_getspecific(pthread_key_t key)" to get the value of the thread local storage and it caches it per thread since it never changes. I had to update the test case to access the thread local data before trying to print it as on Apple OS variants, thread locals are not available unless they have been accessed at least one by the current thread. I also added a new lldb::ValueType named "eValueTypeVariableThreadLocal" so that we can ask SBValue objects for their ValueType and be able to tell when we have a thread local variable. <rdar://problem/23308080> llvm-svn: 274366
* SBValue::CreateValueFromData didn’t check whether the SBType passed into ↵Enrico Granata2016-05-231-3/+4
| | | | | | | | it is in fact a valid type - this can lead to LLDB crashing upon access Committing on behalf of Sebastian Theophil llvm-svn: 270456
* second pass over removal of Mutex and ConditionSaleem Abdulrasool2016-05-191-9/+8
| | | | llvm-svn: 270024
* Make the error return more explicit when an SBValue has no value.Jim Ingham2015-10-301-0/+3
| | | | llvm-svn: 251722
* [SBValue] Add a method GetNumChildren(uint32_t max)Siva Chandra2015-10-211-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Along with this, support for an optional argument to the "num_children" method of a Python synthetic child provider has also been added. These have been added with the following use case in mind: Synthetic child providers currently have a method "has_children" and "num_children". While the former is good enough to know if there are children, it does not give any insight into how many children there are. Though the latter serves this purpose, calculating the number for children of a data structure could be an O(N) operation if the data structure has N children. The new method added in this change provide a middle ground. One can call GetNumChildren(K) to know if a child exists at an index K which can be as large as the callers tolerance can be. If the caller wants to know about children beyond K, it can make an other call with 2K. If the synthetic child provider maintains state about it counting till K previosly, then the next call is only an O(K) operation. Infact, all calls made progressively with steps of K will be O(K) operations. Reviewers: vharron, clayborg, granata.enrico Subscribers: labath, lldb-commits Differential Revision: http://reviews.llvm.org/D13778 llvm-svn: 250930
* Fix build with python disabled after r249597Keno Fischer2015-10-161-4/+0
| | | | | | | | | | | | | | | Summary: r249597 introduced a usage of GetTypeSummary in lldb-mi. That function used to only be available when python is enabled. However, there is no reason for that anymore since that is now dealt with at a different abstraction layer. Reviewers: ki.stfu, evgeny777, clayborg, granata.enrico Subscribers: elehcim, brucem, lldb-commits Differential Revision: http://reviews.llvm.org/D13577 llvm-svn: 250494
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-241-2/+2
| | | | | | | | | | | | | | | | | | | | lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
* ClangASTType is now CompilerType.Greg Clayton2015-08-111-5/+5
| | | | | | This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc). llvm-svn: 244689
* Deprecate `SBValue::TypeIsPointerType`.Chaoren Lin2015-07-271-13/+2
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11540 llvm-svn: 243333
* Fix an issue where an SBValue could end up capturing a synthetic value and ↵Enrico Granata2015-06-241-3/+9
| | | | | | | | would then be unable to return the non-synthetic version thereof This patch makes the backing ValueImpl always store the root-most value no matter the "flavor" that is initially passed into it llvm-svn: 240578
* Cleanup the code a bit to make it more readable. Greg Clayton2015-06-221-4/+14
| | | | | | | | Add some if/then to avoid calling a function to get dynamic/synthetic types if we know we aren't going to need to call it. Avoid calling a function that returns a shared pointer twice: once for testing it and once for assigning it (even though that shared pointer is cached inside the value object), it just makes the code a bit clearer. llvm-svn: 240299
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-291-2/+0
| | | | | | | | | | | | | Since interaction with the python interpreter is moving towards being more isolated, we won't be able to include this header from normal files anymore, all includes of it should be localized to the python library which will live under source/bindings/API/Python after a future patch. None of the files that were including this header actually depended on it anyway, so it was just a dead include in every single instance. llvm-svn: 238581
* Remove duplicated code for synthetic array members.Bruce Mitchener2015-02-261-8/+1
| | | | | | | | | | | | | | | | | Summary: The code for GetSyntheticArrayMemberFromPointer and GetSyntheticArrayMemberFromArray was identical, so just collapse the the methods into one. Reviewers: granata.enrico, clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D7911 llvm-svn: 230708
* Introduce the notion of "runtime support values"Enrico Granata2015-02-111-0/+16
| | | | | | | | | | | | 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
* Fix evaluation commands (MI)Ilia K2015-02-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: These changes include: * Fix -var-create to be able use current frame '*' (MI) * Fix print-values option in -var-update (MI) * Fix 'variable doesn't exist' error in -var-show-attributes (MI) * Mark print-values option as 'handled-by-cmd' in -var-update (MI) * Fix SBValue::GetValueDidChange if value was changed * Fix lldb-mi: -data-evaluate-expression shows undef vars. Before this fix -data-evaluate-expression perceives undefined variables as strings: ``` (gdb) -data-evaluate-expression undef ^done,value="undef" ``` * Minor fix: -data-evaluate-expression uses IsUnknownValue() * Enable MiEvaluateTestCase test All test pass on OS X. Reviewers: abidh, clayborg Subscribers: lldb-commits, clayborg, abidh Differential Revision: http://reviews.llvm.org/D7463 llvm-svn: 228414
* Provide CreateValueFromData,Expression at the SBTarget level as well as the ↵Enrico Granata2014-12-171-44/+10
| | | | | | SBValue level; and also make all the implenentations agree on using the matching ValueObject::Create instead of doing code copypastas llvm-svn: 224460
* Add the ability for an SBValue to create a persisted version of itself.Enrico Granata2014-12-081-0/+13
| | | | | | | | | | | | 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-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
* Introduce the notion of "type summary options" as flags that can be passed ↵Enrico Granata2014-11-061-0/+23
| | | | | | | | | | | | | 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/+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
* Introduce the concept of a "display name" for typesEnrico Granata2014-05-171-0/+25
| | | | | | | | | | | | | | | | | | | | | | 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
* sweep up -Wformat warnings from gccSaleem Abdulrasool2014-04-041-151/+229
| | | | | | | This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
* Better error reporting when a variable can't beSean Callanan2014-02-281-2/+3
| | | | | | | | | | | read during materialization. First of all, report if we can't read the data for some reason. Second, consult the ValueObject's error and report that if there's some problem. <rdar://problem/16074201> llvm-svn: 202552
* Do a little more prevention against SBValues getting used after the world ↵Jim Ingham2013-12-061-2/+21
| | | | | | has been torn down around them. llvm-svn: 196616
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-4/+4
| | | | | | | | | | pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
* Add a new base class, Frame. It is a pure virtual function whichJason Molenda2013-11-021-4/+4
| | | | | | | | | | | | | | | | | | | | | defines a protocol that all subclasses will implement. StackFrame is currently the only subclass and the methods that Frame vends are nearly identical to StackFrame's old methods. Update all callers to use Frame*/Frame& instead of pointers to StackFrames. This is almost entirely a mechanical change that touches a lot of the code base so I'm committing it alone. No new functionality is added with this patch, no new subclasses of Frame exist yet. I'll probably need to tweak some of the separation, possibly moving some of StackFrame's methods up in to Frame, but this is a good starting point. <rdar://problem/15314068> llvm-svn: 193907
* SBValue::GetValueAsUnsigned()/GetValueAsSigned() should not replicate the ↵Enrico Granata2013-10-311-15/+13
| | | | | | Scalar manipulation logic found in ValueObject, but rather just call down to it llvm-svn: 193786
* <rdar://problem/15144376>Enrico Granata2013-10-291-5/+5
| | | | | | | | | | | | This commit reimplements the TypeImpl class (the class that backs SBType) in terms of a static,dynamic type pair This is useful for those cases when the dynamic type of an ObjC variable can only be obtained in terms of an "hollow" type with no ivars In that case, we could either go with the static type (+iVar information) or with the dynamic type (+inheritance chain) With the new TypeImpl implementation, we try to combine these two sources of information in order to extract as much information as possible This should improve the functionality of tools that are using the SBType API to do extensive dynamic type inspection llvm-svn: 193564
* <rdar://problem/14028923>Enrico Granata2013-10-081-4/+4
| | | | | | | Implement SBTarget::CreateValueFromAddress() with a behavior equivalent to SBValue::CreateValueFromAddress() (but without the need to grab an SBValue first just as a starting point to make up another SBValue out of whole cloth) llvm-svn: 192239
* <rdar://problem/14393032>Enrico Granata2013-09-301-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DumpValueObject() 2.0 This checkin restores pre-Xcode5 functionality to the "po" (expr -O) command: - expr now has a new --description-verbosity (-v) argument, which takes either compact or full as a value (-v is the same as -vfull) When the full mode is on, "po" will show the extended output with type name, persistent variable name and value, as in (lldb) expr -O -v -- foo (id) $0 = 0x000000010010baf0 { 1 = 2; 2 = 3; } When -v is omitted, or -vcompact is passed, the Xcode5-style output will be shown, as in (lldb) expr -O -- foo { 1 = 2; 2 = 3; } - for a non-ObjectiveC object, LLDB will still try to retrieve a summary and/or value to display (lldb) po 5 5 -v also works in this mode (lldb) expr -O -vfull -- 5 (int) $4 = 5 On top of that, this is a major refactoring of the ValueObject printing code. The functionality is now factored into a ValueObjectPrinter class for easier maintenance in the future DumpValueObject() was turned into an instance method ValueObject::Dump() which simply calls through to the printer code, Dump_Impl has been removed Test case to follow llvm-svn: 191694
* merge lldb-platform-work branch (and assorted fixes) into trunkDaniel Malea2013-08-261-64/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This merge brings in the improved 'platform' command that knows how to interface with remote machines; that is, query OS/kernel information, push and pull files, run shell commands, etc... and implementation for the new communication packets that back that interface, at least on Darwin based operating systems via the POSIXPlatform class. Linux support is coming soon. Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS X Mountain Lion. Additional improvements (not in the source SVN branch 'lldb-platform-work'): - cmake build scripts for lldb-platform - cleanup test suite - documentation stub for qPlatform_RunCommand - use log class instead of printf() directly - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely. - add new logging category 'platform' Reviewers: Matt Kopec, Greg Clayton Review: http://llvm-reviews.chandlerc.com/D1493 llvm-svn: 189295
OpenPOWER on IntegriCloud