summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core/ValueObject.cpp
Commit message (Collapse)AuthorAgeFilesLines
* This fixes the build I previously broke - and actually makes the test case ↵Enrico Granata2015-03-121-24/+74
| | | | | | work just like I promised llvm-svn: 232115
* Remove duplicated code for synthetic array members.Bruce Mitchener2015-02-261-52/+6
| | | | | | | | | | | | | | | | | 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
* Make a more complete fix for always supplying an execution context when ↵Greg Clayton2015-02-121-4/+4
| | | | | | | | | | getting byte sizes from types. There was a test in the test suite that was triggering the backtrace logging output that requested that the client pass an execution context. Sometimes we need the process for Objective C types because our static notion of the type might not align with the reality when being run in a live runtime. Switched from an "ExecutionContext *" to an "ExecutionContextScope *" for greater ease of use. llvm-svn: 228892
* Introduce the notion of "runtime support values"Enrico Granata2015-02-111-0/+15
| | | | | | | | | | | | 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
* Move several GetByteSize() calls over to the brave new world of taking an ↵Enrico Granata2015-01-281-4/+10
| | | | | | | | | | ExecutionContext* And since enough of these are doing the right thing, add a test case to verify we are doing the right thing with freeze drying ObjC object types Fixes rdar://18092770 llvm-svn: 227282
* Preparatory infrastructural work to support dynamically determining sizes of ↵Enrico Granata2015-01-281-4/+4
| | | | | | | | | | | | ObjC types via the runtime This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for) The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee) This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet llvm-svn: 227274
* Fix indentation in ValueObject.cpp (test commit)Tamas Berghammer2015-01-231-2/+2
| | | | llvm-svn: 226906
* Add an API to ValueObject that iterates over the entire parent chain via a ↵Enrico Granata2015-01-221-8/+14
| | | | | | callback, and rewrite GetRoot() in terms of this general iteration API. NFC llvm-svn: 226771
* Allow individual ValueObjects to pick their preferred display languageEnrico Granata2015-01-211-12/+23
| | | | | | | | Most of the time, we can use context information just fine to choose a language (i.e. the language of the frame that the root object was defined in, if any); but in some cases, synthetic children may be fabricated as root frame-less entities, and then we wouldn't know any better This patch allows (internal) synthetic child providers to set a display language on the children they generate, should they so choose llvm-svn: 226634
* This patch fixes my think-o in ValueObject::UpdateValueIfNeeded() about the ↵Enrico Granata2015-01-081-2/+2
| | | | | | | | | right thing to assert() It also comes with a (rudimentary) test case that gets itself in a failed update scenario, and checks that we don't crash This is the easiest case I could think of that forces the failed update case Zachary was seeing llvm-svn: 225463
* Fix a problem where a ValueObject could fail to update itself, but since it ↵Enrico Granata2015-01-081-1/+1
| | | | | | was previously valid, we'd have an old checksum to compare aginst no new checksum (because failure to update), and assert() and die. Fix the problem by only caring about this assertion logic if updates succeed llvm-svn: 225418
* Cleanup some redundant codeEnrico Granata2014-12-201-3/+1
| | | | llvm-svn: 224659
* Provide CreateValueFromData,Expression at the SBTarget level as well as the ↵Enrico Granata2014-12-171-2/+13
| | | | | | SBValue level; and also make all the implenentations agree on using the matching ValueObject::Create instead of doing code copypastas llvm-svn: 224460
* Remove the last vestige of the world before data formatters :-)Enrico Granata2014-12-101-59/+4
| | | | | | | | Function pointers had a summary generated for them bypassing formatters, directly as part of the ValueObject subsystem This patch transitions that code into a hardcoded summary llvm-svn: 223906
* Extend ValueObject::GetExpressionPath() to do something reasonable for ↵Enrico Granata2014-12-091-0/+40
| | | | | | | | | | | | | | | | | | | synthetic children Because of the way they are created, synthetic children cannot (in general) have a sane expression path A solution to this would be letting the parent front-end generate expression paths for its children Doing so requires a significant amount of refactoring, and might not always lead to better results (esp. w.r.t. C++ templates) This commit takes a simpler approach: - if a synthetic child is of pointer type and it's a target pointer, then emit *((T)value) - if a synthetic child is a non-pointer, but its location is in the target, then emit *((T*)loadAddr) - if a synthetic child has a value, emit ((T)value) - else, don't emit anything Fixes rdar://18442386 llvm-svn: 223836
* Fixed ValueObject::UpdateValueIfNeeded to keepSean Callanan2014-12-091-10/+47
| | | | | | | | | | track of the checksum of the object so we can track if it is modified. This fixes a testcase (test/expression_command/issue_11588) on OS X. Patch by Enrico Granata. llvm-svn: 223830
* This patch does a few things:Enrico Granata2014-12-091-2/+16
| | | | | | | | | | - adds a new flag to mark ValueObjects as "synthetic children generated" - vends new Create functions as part of the SyntheticChildrenFrontEnd that set the flag automatically - moves synthetic child providers over to using these new functions No visible feature change, but preparatory work for feature change llvm-svn: 223819
* Add the ability for an SBValue to create a persisted version of itself.Enrico Granata2014-12-081-0/+26
| | | | | | | | | | | | 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-7/+10
| | | | | | 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
* This is a large, but clearical, commit that enables the C++ formatters to ↵Enrico Granata2014-11-061-1/+1
| | | | | | take on the additional TypeSummaryOptions argument. It is still not used for anything, but it is now there. Adding support for this extra argument to Python formatters will follow suit llvm-svn: 221486
* Introduce the notion of "type summary options" as flags that can be passed ↵Enrico Granata2014-11-061-1/+40
| | | | | | | | | | | | | 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
* Add a setting escape-non-printables that drives whether the StringPrinter ↵Enrico Granata2014-11-051-2/+1
| | | | | | | | | | | should or should not escape sequences such as \t, \n, .. and generally any non-printing character The recent StringPrinter changes made this behavior the default, and the setting defaults to yes If you want to change this behavior and see non-printables unescaped (e.g. "a\tb" as "a b"), set it to false Fixes rdar://12969594 llvm-svn: 221399
* Also port the C string reading code in ValueObject over to using ↵Enrico Granata2014-10-301-32/+36
| | | | | | StringPrinter API llvm-svn: 220917
* Expose the type-info flags at the public API layer. These flags provide much ↵Enrico Granata2014-10-211-48/+48
| | | | | | more informational content to consumers of the LLDB API than the existing TypeClass. Part of the fix for rdar://18517593 llvm-svn: 220322
* Remove default case from a fully covered switch.Eric Christopher2014-10-111-1/+0
| | | | llvm-svn: 219548
* Add an API on ValueObject to retrieve the desired dynamic/synthetic ↵Enrico Granata2014-10-091-0/+50
| | | | | | combination all at once, if available, working somewhat hard to avoid returning an invalid ValueObject in the process llvm-svn: 219423
* Extend synthetic children to produce synthetic values (as in, those that ↵Enrico Granata2014-10-081-5/+11
| | | | | | | | | | | | | | | | | GetValueAsUnsigned(), GetValueAsCString() would return) The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function. If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value The rationale for doing things this way is twofold: - there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial - we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature Comes with a test case llvm-svn: 219330
* Start plumbing the type validator logic through to the ValueObjects; allow a ↵Enrico Granata2014-09-051-2/+25
| | | | | | ValueObject to have a validator, to update it from the FormatManager, and to retrieve (and cache) the result of the validation llvm-svn: 217282
* It was pointed out to me that an offset of 0 makes sense for ObjC, but not ↵Enrico Granata2014-08-261-2/+1
| | | | | | always for C++, and this API claims to be general enough that it should not drop C++ usability on the floor for no good reason. Fix it with an explicit offset argument llvm-svn: 216487
* Add an API on ValueObject to generate a 'synthetic child' of base class ↵Enrico Granata2014-08-261-0/+42
| | | | | | type. Note that in this commit, the term synthetic child is not meant to refer to data formatters, but to the programmatically-generated children stored inside a ValueObject itself llvm-svn: 216483
* Add an accessor to ValueObject that determines if the object represents a ↵Enrico Granata2014-08-191-0/+20
| | | | | | base class, and also returns the depth of base-class-ness. For instance if one has class C : public B {} class B : public A {}, the value for A nested in B nested in C would be a base class of depth 2 llvm-svn: 216032
* LLDB now correctly handles virtual inheritance.Greg Clayton2014-07-191-4/+36
| | | | | | | | Test case added as well. <rdar://problem/16785904> llvm-svn: 213433
* Introduce the concept of a "display name" for typesEnrico Granata2014-05-171-0/+6
| | | | | | | | | | | | | | | | | | | | | | 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
* <rdar://problem/16477472>Enrico Granata2014-04-091-4/+3
| | | | | | | | | Set the correct FormatManager revision before starting to figure out the new formatters This can avoid entering some corner cases where as part of figuring out formatters we try to figure out dynamic types, and in turn that causes us to go back in trying to fetch new formatters - it is not only a futile exercise, it's also prone to endless recursion This would only cause a behavior change if getting this chain started would eventually cause something to run and alter the formatters, a very unlikely if at all possible sequence of events llvm-svn: 205928
* sweep up -Wformat warnings from gccSaleem Abdulrasool2014-04-041-9/+7
| | | | | | | 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
* <rdar://problem/16424592>Enrico Granata2014-03-311-1/+1
| | | | | | | | For some reason, the libc++ vector<bool> data formatter was essentially a costly no-up, doing everything required of it, except actually generating the child values! This restores its functionality llvm-svn: 205259
* Fix Windows build using portable types for formatting the log outputsDeepak Panickal2014-03-031-3/+3
| | | | llvm-svn: 202723
* Better error reporting when a variable can't beSean Callanan2014-02-281-4/+5
| | | | | | | | | | | 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
* <rdar://problem/16006373>Enrico Granata2014-02-151-12/+4
| | | | | | | Revert the spirit of r199857 - a convincing case can be made that overriding a summary's format markers behind its back is not the right thing to do This commit reverts the behavior of the code to the previous model, and changes the test case to validate the opposite of what it was validating before llvm-svn: 201455
* Merging the iohandler branch back into main. Greg Clayton2014-01-271-1/+2
| | | | | | | | | | | | The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
* Don't copy entire value into m_data unless we need to. If we did this and ↵Greg Clayton2014-01-231-2/+2
| | | | | | the entire variable failed to be read, we wouldn't be able to display any actual values that were in good memory. This will also make things more efficient by not have every struct/union/class/array copy its entire value into a ValueObject.m_data even though no one was using it. llvm-svn: 199953
* If a user specifies a format option to frame variable or expression, that ↵Enrico Granata2014-01-231-4/+12
| | | | | | | | format should prevail over whatever format(s) a summary specifies (see test case for an example) llvm-svn: 199857
* New and improved data formatter for std::shared_ptr<> and std::weak_ptr<>Enrico Granata2014-01-081-2/+8
| | | | llvm-svn: 198724
* Add a new way to bind a format to a type: by enum typeEnrico Granata2013-12-281-2/+2
| | | | | | | | | | | The "type format add" command gets a new flag --type (-t). If you pass -t <sometype>, upon fetching the value for an object of your type, LLDB will display it as-if it was of enumeration type <sometype> This is useful in cases of non-contiguous enums where there are empty gaps of unspecified values, and as such one cannot type their variables as the enum type, but users would still like to see them as-if they were of the enum type (e.g. DWARF field types with their user-reserved ranges) The SB API has also been improved to handle both types of formats, and a test case is added llvm-svn: 198105
* Centralize the code for GetValueAsCString() in TypeFormatImpl (the ↵Enrico Granata2013-12-221-79/+15
| | | | | | | | | | | implementing class of "type format ...") TypeFormatImpl used to just wrap a Format (and Flags for matching), and then ValueObject itself would do the printing deed With this checkin, the responsibility of generating a value string is centralized in the data formatter (as it should, and already is for summaries) This change is good practice per se, and should also enable us to extend the type format mechanism in a cleaner way llvm-svn: 197874
* Fix the test suite after the changes made in revision 196616 exposed issues ↵Greg Clayton2013-12-101-1/+2
| | | | | | | | in the test suite. We must make sure that all ValueObject objects always contain a valid target. llvm-svn: 196983
* For logical backtrace work, lldb needs to track Module unloads etc & ↵Greg Clayton2013-12-061-0/+1
| | | | | | | | | | symoblicate an address based on a point in time <rdar://problem/15314403> This patch adds a new lldb_private::SectionLoadHistory class that tracks what shared libraries were loaded given a process stop ID. This allows us to keep a history of the sections that were loaded for a time T. Many items in history objects will rely upon the process stop ID in the future. llvm-svn: 196557
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-2/+2
| | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | | | | | 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-0/+21
| | | | | | Scalar manipulation logic found in ValueObject, but rather just call down to it llvm-svn: 193786
OpenPOWER on IntegriCloud