Commit Graph

23 Commits

Author SHA1 Message Date
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
Greg Clayton faac111870 <rdar://problem/13421412>
Many "byte size" members and variables were using a mixture of uint32_t and size_t. Switching over to using uint64_t everywhere.

llvm-svn: 177091
2013-03-14 18:31:44 +00:00
Greg Clayton c7bece56fa <rdar://problem/13069948>
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.

So I defined a new "lldb::offset_t" which should be used for all file offsets.

After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.

Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.

llvm-svn: 173463
2013-01-25 18:06:21 +00:00
Daniel Malea 89660bf795 More Linux warnings fixes (remove default labels as needed):
- as per http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations

Patch by Matt Kopec!

llvm-svn: 169633
2012-12-07 20:51:09 +00:00
Greg Clayton 9407302d37 Make const result value objects able to return dynamic types.
Modified the heap.py to be able to correctly indentify the exact ivar for the "ptr_refs" command no matter how deep the ivar is in a class hierarchy. Also fixed the ability for the heap command to symbolicate the stack backtrace when MallocStackLogging is set in the environment and the "--stack" option was specified.

llvm-svn: 159883
2012-07-07 01:22:45 +00:00
Bill Wendling c359aafc55 Order the initializations so that they reflect how they're declared in the class.
llvm-svn: 154055
2012-04-04 21:19:57 +00:00
Greg Clayton 84db9105d2 <rdar://problem/11113279>
Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not). 

This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method.

This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB.

llvm-svn: 153482
2012-03-26 23:03:23 +00:00
Sean Callanan 7277284f87 Added support for looking up the complete type for
Objective-C classes.  This allows LLDB to find
ivars declared in class extensions in modules other
than where the debugger is currently stopped (we
already supported this when the debugger was
stopped in the same module as the definition).

This involved the following main changes:

- The ObjCLanguageRuntime now knows how to hunt
  for the authoritative version of an Objective-C
  type.  It looks for the symbol indicating a
  definition, and then gets the type from the
  module containing that symbol.

- ValueObjects now report their type with a
  potential override, and the override is set if
  the type of the ValueObject is an Objective-C
  class or pointer type that is defined somewhere
  other than the original reported type.  This
  means that "frame variable" will always use the
  complete type if one is available.

- The ClangASTSource now looks for the complete
  type when looking for ivars.  This means that
  "expr" will always use the complete type if one
  is available.

- I added a testcase that verifies that both
  "frame variable" and "expr" work.

llvm-svn: 151214
2012-02-22 23:57:45 +00:00
Sean Callanan 31a8d051dd Fixed a dangling pointer bug associated with the
result variable on a "finish" statement.  The
ownership of the result value was not being properly
assigned to the newly-created persistent result
variable; now it is.

llvm-svn: 147587
2012-01-05 01:11:09 +00:00
Jim Ingham 73ca05a2a0 Add the ability to capture the return value in a thread's stop info, and print it
as part of the thread format output.
Currently this is only done for the ThreadPlanStepOut.
Add a convenience API ABI::GetReturnValueObject.
Change the ValueObject::EvaluationPoint to BE an ExecutionContextScope, rather than
trying to hand out one of its subsidiary object's pointers.  That way this will always
be good.

llvm-svn: 146806
2011-12-17 01:35:57 +00:00
Johnny Chen b456b792e0 http://llvm.org/bugs/show_bug.cgi?id=11588
valobj.AddressOf() returns None when an address is expected in a SyntheticChildrenProvider

Patch from Enrico Granata:

The problem was that the frozen object created by the expression parser was a copy of the contents of the StgClosure, rather than a pointer to it. Thus, the expression parser was correctly computing the result of the arithmetic&cast operation along with its address, but only saving it in the live object. This meant that the frozen copy acted as an address-less variable, hence the problem.

The fix attached to this email lets the expression parser store the "live address" in the frozen copy of the address when the object is built without a valid address of its own.
Doing so, along with delegating ValueObjectConstResult to calculate its own address when necessary, solves the issue. I have also added a new test case to check for regressions in this area, and checked that existing test cases pass correctly.

llvm-svn: 146768
2011-12-16 23:04:52 +00:00
Enrico Granata 9128ee2f7a Redesign of the interaction between Python and frozen objects:
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
   a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
   in frozen objects ; now such reads transparently move from host to target as required
 - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
   removed code that enabled to recognize an expression result VO as such
 - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
   representing a T* or T[], and doing dereferences transparently
   in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
 - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
   en lieu of doing the raw read itself
 - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
   this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
   in public layer this returns an SBData, just like GetPointeeData()
 - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
   the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
   of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
 - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
 of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
 addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types

llvm-svn: 139160
2011-09-06 19:20:51 +00:00
Greg Clayton e305594277 Centralize all of the type name code so that we always strip the leading
"struct ", "class ", and "union " from the start of any type names that are
extracted from clang QualType objects. I had to fix test suite cases that
were expecting the struct/union/class prefix to be there.

llvm-svn: 134132
2011-06-30 02:28:26 +00:00
Jim Ingham 58b59f9522 Fix up how the ValueObjects manage their life cycle so that you can hand out a shared
pointer to a ValueObject or any of its dependent ValueObjects, and the whole cluster will
stay around as long as that shared pointer stays around.

llvm-svn: 130035
2011-04-22 23:53:53 +00:00
Jim Ingham 6035b67d2c Convert ValueObject to explicitly maintain the Execution Context in which they were created, and then use that when they update themselves. That means all the ValueObject evaluate me type functions that used to require a Frame object now do not. I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated.
llvm-svn: 128593
2011-03-31 00:19:25 +00:00
Greg Clayton e0d378b334 Fixed the LLDB build so that we can have private types, private enums and
public types and public enums. This was done to keep the SWIG stuff from
parsing all sorts of enums and types that weren't needed, and allows us to
abstract our API better.

llvm-svn: 128239
2011-03-24 21:19:54 +00:00
Greg Clayton 6beaaa680a A few of the issue I have been trying to track down and fix have been due to
the way LLDB lazily gets complete definitions for types within the debug info.
When we run across a class/struct/union definition in the DWARF, we will only
parse the full definition if we need to. This works fine for top level types
that are assigned directly to variables and arguments, but when we have a 
variable with a class, lets say "A" for this example, that has a member:
"B *m_b". Initially we don't need to hunt down a definition for this class
unless we are ever asked to do something with it ("expr m_b->getDecl()" for
example). With my previous approach to lazy type completion, we would be able
to take a "A *a" and get a complete type for it, but we wouldn't be able to
then do an "a->m_b->getDecl()" unless we always expanded all types within a
class prior to handing out the type. Expanding everything is very costly and
it would be great if there were a better way.

A few months ago I worked with the llvm/clang folks to have the 
ExternalASTSource class be able to complete classes if there weren't completed
yet:

class ExternalASTSource {
....

    virtual void
    CompleteType (clang::TagDecl *Tag);
    
    virtual void 
    CompleteType (clang::ObjCInterfaceDecl *Class);
};

This was great, because we can now have the class that is producing the AST
(SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources
and the object that creates the forward declaration types can now also
complete them anywhere within the clang type system.

This patch makes a few major changes:
- lldb_private::Module classes now own the AST context. Previously the TypeList
  objects did.
- The DWARF parsers now sign up as an external AST sources so they can complete
  types.
- All of the pure clang type system wrapper code we have in LLDB (ClangASTContext,
  ClangASTType, and more) can now be iterating through children of any type,
  and if a class/union/struct type (clang::RecordType or ObjC interface) 
  is found that is incomplete, we can ask the AST to get the definition. 
- The SymbolFileDWARFDebugMap class now will create and use a single AST that
  all child SymbolFileDWARF classes will share (much like what happens when
  we have a complete linked DWARF for an executable).
  
We will need to modify some of the ClangUserExpression code to take more 
advantage of this completion ability in the near future. Meanwhile we should
be better off now that we can be accessing any children of variables through
pointers and always be able to resolve the clang type if needed.

llvm-svn: 123613
2011-01-17 03:46:26 +00:00
Greg Clayton 8b2fe6dcbd Modified LLDB expressions to not have to JIT and run code just to see variable
values or persistent expression variables. Now if an expression consists of
a value that is a child of a variable, or of a persistent variable only, we
will create a value object for it and make a ValueObjectConstResult from it to
freeze the value (for program variables only, not persistent variables) and
avoid running JITed code. For everything else we still parse up and JIT code
and run it in the inferior. 

There was also a lot of clean up in the expression code. I made the 
ClangExpressionVariables be stored in collections of shared pointers instead
of in collections of objects. This will help stop a lot of copy constructors on
these large objects and also cleans up the code considerably. The persistent
clang expression variables were moved over to the Target to ensure they persist
across process executions.

Added the ability for lldb_private::Target objects to evaluate expressions.
We want to evaluate expressions at the target level in case we aren't running
yet, or we have just completed running. We still want to be able to access the
persistent expression variables between runs, and also evaluate constant 
expressions. 

Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects
can now dump their contents with the UUID, arch and full paths being logged with
appropriate prefix values.

Thread hardened the Communication class a bit by making the connection auto_ptr
member into a shared pointer member and then making a local copy of the shared
pointer in each method that uses it to make sure another thread can't nuke the
connection object while it is being used by another thread.

Added a new file to the lldb/test/load_unload test that causes the test a.out file
to link to the libd.dylib file all the time. This will allow us to test using
the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else.

llvm-svn: 121745
2010-12-14 02:59:59 +00:00
Greg Clayton 526e5afb2d Modified the lldb_private::Type clang type resolving code to handle three
cases when getting the clang type:
- need only a forward declaration
- need a clang type that can be used for layout (members and args/return types)
- need a full clang type

This allows us to partially parse the clang types and be as lazy as possible.
The first case is when we just need to declare a type and we will complete it
later. The forward declaration happens only for class/union/structs and enums.
The layout type allows us to resolve the full clang type _except_ if we have
any modifiers on a pointer or reference (both R and L value). In this case
when we are adding members or function args or return types, we only need to
know how the type will be laid out and we can defer completing the pointee
type until we later need it. The last type means we need a full definition for
the clang type.

Did some renaming of some enumerations to get rid of the old "DC" prefix (which
stands for DebugCore which is no longer around).

Modified the clang namespace support to be almost ready to be fed to the
expression parser. I made a new ClangNamespaceDecl class that can carry around
the AST and the namespace decl so we can copy it into the expression AST. I
modified the symbol vendor and symbol file plug-ins to use this new class.

llvm-svn: 118976
2010-11-13 03:52:47 +00:00
Jim Ingham e2f8841d34 Mark a ValueObjectConstResult as valid if it is created with some data, don't wait till it gets updated.
llvm-svn: 116633
2010-10-15 22:47:36 +00:00
Greg Clayton 8f92f0a35c Fixed an expression parsing issue where if you were stopped somewhere without
debug information and you evaluated an expression, a crash would occur as a
result of an unchecked pointer.

Added the ability to get the expression path for a ValueObject. For a rectangle
point child "x" the expression path would be something like: "rect.top_left.x".
This will allow GUI and command lines to get ahold of the expression path for
a value object without having to explicitly know about the hierarchy. This
means the ValueObject base class now has a "ValueObject *m_parent;" member.
All ValueObject subclasses now correctly track their lineage and are able
to provide value expression paths as well.

Added a new "--flat" option to the "frame variable" to allow for flat variable
output. An example of the current and new outputs:

(lldb) frame variable 
argc = 1
argv = 0x00007fff5fbffe80
pt = {
  x = 2
  y = 3
}
rect = {
  bottom_left = {
    x = 1
    y = 2
  }
  top_right = {
    x = 3
    y = 4
  }
}
(lldb) frame variable --flat 
argc = 1
argv = 0x00007fff5fbffe80
pt.x = 2
pt.y = 3
rect.bottom_left.x = 1
rect.bottom_left.y = 2
rect.top_right.x = 3
rect.top_right.y = 4


As you can see when there is a lot of hierarchy it can help flatten things out.
Also if you want to use a member in an expression, you can copy the text from
the "--flat" output and not have to piece it together manually. This can help
when you want to use parts of the STL in expressions:

(lldb) frame variable --flat
argc = 1
argv = 0x00007fff5fbffea8
hello_world._M_dataplus._M_p = 0x0000000000000000
(lldb) expr hello_world._M_dataplus._M_p[0] == '\0'

llvm-svn: 116532
2010-10-14 22:52:14 +00:00
Greg Clayton b71f384455 Added the notion that a value object can be constant by adding:
bool ValueObject::GetIsConstant() const;
    void ValueObject::SetIsConstant();

This will stop anything from being re-evaluated within the value object so
that constant result value objects can maintain their frozen values without
anything being updated or changed within the value object.

Made it so the ValueObjectConstResult can be constructed with an 
lldb_private::Error object to allow for expression results to have errors.

Since ValueObject objects contain error objects, I changed the expression
evaluation in ClangUserExpression from 

    static Error
    ClangUserExpression::Evaluate (ExecutionContext &exe_ctx, 
                                  const char *expr_cstr, 
                                  lldb::ValueObjectSP &result_valobj_sp);

to:

    static lldb::ValueObjectSP
    Evaluate (ExecutionContext &exe_ctx, const char *expr_cstr);
    
Even though expression parsing is borked right now (pending fixes coming from
Sean Callanan), I filled in the implementation for:
    
    SBValue SBFrame::EvaluateExpression (const char *expr);
    
Modified all expression code to deal with the above changes.

llvm-svn: 115589
2010-10-05 03:13:51 +00:00
Greg Clayton 1d3afba3a3 Added a new ValueObject type that will be used to freeze dry expression
results. The clang opaque type for the expression result will be added to the
Target's ASTContext, and the bytes will be stored in a DataBuffer inside
the new object. The class is named: ValueObjectConstResult

Now after an expression is evaluated, we can get a ValueObjectSP back that
contains a ValueObjectConstResult object.

Relocated the value object dumping code into a static function within
the ValueObject class instead of being in the CommandObjectFrame.cpp file
which is what contained the code to dump variables ("frame variables").

llvm-svn: 115578
2010-10-05 00:00:42 +00:00