Commit Graph

229 Commits

Author SHA1 Message Date
Enrico Granata 622be238eb Expose the type-info flags at the public API layer. These flags provide much more informational content to consumers of the LLDB API than the existing TypeClass. Part of the fix for rdar://18517593
llvm-svn: 220322
2014-10-21 20:52:14 +00:00
Eric Christopher 53b293e447 Remove default case from a fully covered switch.
llvm-svn: 219548
2014-10-11 00:00:08 +00:00
Enrico Granata 538a88aac7 Add an API on ValueObject to retrieve the desired dynamic/synthetic combination all at once, if available, working somewhat hard to avoid returning an invalid ValueObject in the process
llvm-svn: 219423
2014-10-09 18:24:30 +00:00
Enrico Granata d07cfd3ae4 Extend synthetic children to produce synthetic values (as in, those that 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
2014-10-08 18:27:36 +00:00
Enrico Granata 744794aa96 Start plumbing the type validator logic through to the ValueObjects; allow a ValueObject to have a validator, to update it from the FormatManager, and to retrieve (and cache) the result of the validation
llvm-svn: 217282
2014-09-05 21:46:22 +00:00
Enrico Granata 59953f0dbe It was pointed out to me that an offset of 0 makes sense for ObjC, but not 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
2014-08-26 21:35:30 +00:00
Enrico Granata 32556cda18 Add an API on ValueObject to generate a 'synthetic child' of base class 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
2014-08-26 20:54:04 +00:00
Enrico Granata a3c8f042cd Add an accessor to ValueObject that determines if the object represents a 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
2014-08-19 22:29:08 +00:00
Greg Clayton 759e7441af LLDB now correctly handles virtual inheritance.
Test case added as well.

<rdar://problem/16785904>

llvm-svn: 213433
2014-07-19 00:12:57 +00:00
Enrico Granata e8daa2f843 Introduce the concept of a "display name" for types
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
2014-05-17 19:14:17 +00:00
Enrico Granata a0db6ed44b <rdar://problem/16477472>
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
2014-04-09 21:06:11 +00:00
Saleem Abdulrasool 324a103619 sweep up -Wformat warnings from gcc
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
2014-04-04 04:06:10 +00:00
Enrico Granata 7ca1c76520 <rdar://problem/16424592>
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
2014-03-31 23:02:25 +00:00
Deepak Panickal 99fbc07600 Fix Windows build using portable types for formatting the log outputs
llvm-svn: 202723
2014-03-03 15:39:47 +00:00
Sean Callanan 866e91c9d4 Better error reporting when a variable can't be
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
2014-02-28 22:27:53 +00:00
Enrico Granata 465f4bc287 <rdar://problem/16006373>
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
2014-02-15 01:24:44 +00:00
Greg Clayton 44d937820b Merging the iohandler branch back into main.
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
2014-01-27 23:43:24 +00:00
Greg Clayton 1e3be5ba2c Don't copy entire value into m_data unless we need to. If we did this and 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
2014-01-23 22:55:05 +00:00
Enrico Granata 90890bba04 If a user specifies a format option to frame variable or expression, that format should prevail over whatever format(s) a summary specifies
(see test case for an example)

llvm-svn: 199857
2014-01-23 01:21:18 +00:00
Enrico Granata 0dba9b33f0 New and improved data formatter for std::shared_ptr<> and std::weak_ptr<>
llvm-svn: 198724
2014-01-08 01:36:59 +00:00
Enrico Granata 30f287fde5 Add a new way to bind a format to a type: by enum type
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
2013-12-28 08:44:02 +00:00
Enrico Granata 4939b98a2c Centralize the code for GetValueAsCString() in TypeFormatImpl (the 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
2013-12-22 09:24:22 +00:00
Greg Clayton eeb15653c6 Fix the test suite after the changes made in revision 196616 exposed issues in the test suite.
We must make sure that all ValueObject objects always contain a valid target.

llvm-svn: 196983
2013-12-10 23:16:40 +00:00
Greg Clayton d5944cd118 For logical backtrace work, lldb needs to track Module unloads etc & 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
2013-12-06 01:12:00 +00:00
Jason Molenda b57e4a1bc6 Roll back the changes I made in r193907 which created a new Frame
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
2013-11-04 09:33:30 +00:00
Jason Molenda f23bf7432c Add a new base class, Frame. It is a pure virtual function which
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
2013-11-02 02:23:02 +00:00
Enrico Granata d7373f69cf SBValue::GetValueAsUnsigned()/GetValueAsSigned() should not replicate the Scalar manipulation logic found in ValueObject, but rather just call down to it
llvm-svn: 193786
2013-10-31 18:57:50 +00:00
Enrico Granata 5e1480c5dc <rdar://problem/13308704>
Fixing a problem where ValueObject::GetPointeeData() would not accept "partial" valid reads (i.e. asking for 10 items and getting only 5 back)
While suboptimal, this situation is not a flat-out failure and could well be caused by legit scenarios, such as hitting a page boundary

Among others, this allows data formatters to print char* buffers allocated under libgmalloc

llvm-svn: 193704
2013-10-30 17:52:44 +00:00
Enrico Granata 38c546320c <rdar://problem/15045059>
One of the things that dynamic typing affects is the count of children a type has
Clear out the flag that makes us blindly believe the children count when a dynamic type change is detected

llvm-svn: 193663
2013-10-30 00:04:29 +00:00
Enrico Granata dc4db5a6eb <rdar://problem/15144376>
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
2013-10-29 00:28:35 +00:00
Enrico Granata b1c6c489ca <rdar://problem/14923930>
Constant ValueObjects should clear their description as well as their summary. Rationale being that both can depend on deeper-than-constified data
so both are subject to changes in "unpredictable" ways
To see this consider repeatedly po'ing a persistent variable of a type whose -description result changes at each invocation

llvm-svn: 192259
2013-10-09 00:33:55 +00:00
Enrico Granata 852cc954db <rdar://problem/11778815>
Formats (as in "type format") are now included in categories
The only bit missing is caching formats along with synthetic children and summaries, which might be now desirable

llvm-svn: 192217
2013-10-08 19:03:22 +00:00
Enrico Granata 4d93b8cdf3 <rdar://problem/14393032>
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
2013-09-30 19:11:51 +00:00
Enrico Granata 5d5f60c391 Target::m_suppress_synthetic_value was a hack required to disable synthetic values while passing an SBValue to a synthetic child provider, or incur an endless recursion
Now that SBValues can be setup to ignore synthetic values, this is no longer necessary, and so m_suppress_synthetic_value can go away

Another Hack Bites the Dust

llvm-svn: 191338
2013-09-24 22:58:37 +00:00
Enrico Granata e2e220a805 <rdar://problem/14071463>
SVN r189964 provided a sample Python script to inspect unordered(multi){set|map} with synthetic children, contribued by Jared Grubb
This checkin converts that sample script to a C++ provider built into LLDB
A test case is also provided

llvm-svn: 190564
2013-09-12 00:48:47 +00:00
Greg Clayton 57ee306789 Huge change to clean up types.
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.

This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.

llvm-svn: 186130
2013-07-11 22:46:58 +00:00
Enrico Granata 2c75f11e86 Adding two new markers to the ${var..} specifier
- %N = show the name of the variable
- %> = show the expression path of the variable

llvm-svn: 184502
2013-06-21 00:04:51 +00:00
Enrico Granata 08a1bb8199 <rdar://problem/14194140>
Adding support for correctly extracting children out of vector types for data formatter purposes

llvm-svn: 184262
2013-06-19 00:00:45 +00:00
Enrico Granata b294fd2037 <rdar://problem/14035604>
Fixing an issue where formats would not propagate from parents to children in all cases
Details follow:
an SBValue has children and those are fetched along with their values
Now, one calls SBValue::SetFormat() on the parent
Technically, the format choices should propagate onto the children (see ValueObject::GetFormat())
But if the children values are already fetched, they won't notice the format change and won't update themselves
This commit fixes that by making ValueObject::GetValueAsCString() check if any format change intervened from the previous call to the current one
A test case is also added

llvm-svn: 183030
2013-05-31 19:18:19 +00:00
Enrico Granata 39d5141085 Small code cleanups
llvm-svn: 183024
2013-05-31 17:43:40 +00:00
Enrico Granata 82fabf89b4 <rdar://problem/13695846>
Enabling LLDB to write to variables that are stored in registers
Previously, this would not work since the Value's Context loses the notion of the data being in a register
We now store an "original" context that comes out of DWARF parsing, and use that context's data when attempting a write

llvm-svn: 180803
2013-04-30 20:45:04 +00:00
Greg Clayton 0fa5c974ef Don't print the type if there is none and don't print "<invalid type>". ValueObjects can be register sets and register groups and dumping those with:
(lldb) script print frame.GetRegisters()

llvm-svn: 180236
2013-04-25 01:05:15 +00:00
Sean Callanan ed185ab5c7 Fixed two problems when reading constant/register
variables in the ValueObject code:

  - Report an error if the variable does not have
    a valid address.

  - Return the contents of the data to GetData(),
    even if the value is constant.

<rdar://problem/13690855>

llvm-svn: 179876
2013-04-19 19:47:32 +00:00
Sean Callanan 389823e995 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().

llvm-svn: 179437
2013-04-13 01:21:23 +00:00
Enrico Granata 4873e52733 <rdar://problem/13623698>
This patch fixes the issue that we were using the C stack as a measure of depth of ValueObject hierarchies, in the sense that we were assuming that recursive ValueObject operations would never be deeper than the stack allows.
This assumption is easy to prove wrong, however.
For instance, after ~10k runs through this loop:
struct node
{
	int value;
	node* child;
	node (int x)
	{
		value = x;
		child = nullptr;
	}
};

int main ()
{
	node root(1);
	node* ptr = &root;
	int j = 2;
	while (1)
	{
		ptr->child = new node(j++);
		ptr = ptr->child;
	}
	return 0;
}

the deepmost child object will be deeper than the stack on most architectures, and we would be unable to display it

This checkin fixes the issue by introducing a notion of root of ValueObject hierarchies.
In a couple cases, we have to use an iterative algorithm instead of going to the root because we want to allow deeper customizations (e.g. formats, dynamic values).
While the patch passes our test suite without regressions, it is a good idea to keep eyes open for any unexpected behavior (recursion can be subtle..)
Also, I am hesitant to introduce a test case since failing at this will not just be marked as an "F", but most definitely crash LLDB.

llvm-svn: 179330
2013-04-11 22:48:58 +00:00
Greg Clayton 5160ce5c72 <rdar://problem/13521159>
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.

All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.

llvm-svn: 178191
2013-03-27 23:08:40 +00:00
Enrico Granata c2a58d73ce <rdar://problem/13365424>
Ensure that option -Y also works for expression as it does for frame variable
Also, if the user passes an explicit format specifier when printing a variable, override the summary's decision to hide the value.

This is required for scenarios like this to work:
(lldb) p/x c
(Class) $0 = 0x0000000100adb7f8 NSObject

Previously this would say:
(lldb) p/x c
(Class) $0 = NSObject

ignoring the explicit format specifier

llvm-svn: 177893
2013-03-25 19:46:48 +00:00
Enrico Granata 9d71afe8cf And then again only compute the more expensive piece of data if need be :-)
llvm-svn: 177812
2013-03-23 01:44:59 +00:00
Enrico Granata 123c39c02b Invert two condition checks to evaluate them in cheapest-to-more-expensive order
llvm-svn: 177810
2013-03-23 01:44:23 +00:00
Enrico Granata 852cce7c1f <rdar://problem/13315663>
commands of the form 
frame variable -f c-string foo
where foo is an arbitrary pointer (e.g. void*) now do the right thing, i.e. they deref the pointer and try to get a c-string at the pointed address instead of dumping the pointer bytes as a string. the old behavior is used as a fallback if things don’t go well

llvm-svn: 177799
2013-03-23 01:12:38 +00:00