Skip to content
  1. Nov 13, 2010
    • Greg Clayton's avatar
      Modified the lldb_private::Type clang type resolving code to handle three · 526e5afb
      Greg Clayton authored
      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
      526e5afb
  2. Nov 02, 2010
  3. Oct 25, 2010
    • Sean Callanan's avatar
      Fixes to Objective-C built-in type handling. · a242417a
      Sean Callanan authored
      Specifically, we fixed handling of the objc_class
      built-in type, which allowed us to pass
      named Objective-C objects to functions,
      call variable list -t on objects safely, etc.
      
      llvm-svn: 117249
      a242417a
  4. Oct 15, 2010
    • Greg Clayton's avatar
      Fixed an expression parsing issue where if you were stopped somewhere without · 8f92f0a3
      Greg Clayton authored
      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
      8f92f0a3
  5. Sep 29, 2010
    • Greg Clayton's avatar
      Fixed the forward declaration issue that was present in the DWARF parser after · 1be10fca
      Greg Clayton authored
      adding methods to C++ and objective C classes. In order to make methods, we
      need the function prototype which means we need the arguments. Parsing these
      could cause a circular reference that caused an  assertion.
      
      Added a new typedef for the clang opaque types which are just void pointers:
      lldb::clang_type_t. This appears in lldb-types.h.
      
      This was fixed by enabling struct, union, class, and enum types to only get
      a forward declaration when we make the clang opaque qual type for these
      types. When they need to actually be resolved, lldb_private::Type will call
      a new function in the SymbolFile protocol to resolve a clang type when it is
      not fully defined (clang::TagDecl::getDefinition() returns NULL). This allows
      us to be a lot more lazy when parsing clang types and keeps down the amount
      of data that gets parsed into the ASTContext for each module. 
      
      Getting the clang type from a "lldb_private::Type" object now takes a boolean
      that indicates if a forward declaration is ok:
      
          clang_type_t lldb_private::Type::GetClangType (bool forward_decl_is_ok);
          
      So function prototypes that define parameters that are "const T&" can now just
      parse the forward declaration for type 'T' and we avoid circular references in
      the type system.
      
      llvm-svn: 115012
      1be10fca
  6. Sep 28, 2010
  7. Jul 22, 2010
    • Greg Clayton's avatar
      Change over to using the definitions for mach-o types and defines to the · e1a916a7
      Greg Clayton authored
      defines that are in "llvm/Support/MachO.h". This should allow ObjectFileMachO
      and ObjectContainerUniversalMachO to be able to be cross compiled in Linux.
      
      Also did some cleanup on the ASTType by renaming it to ClangASTType and
      renaming the header file. Moved a lot of "AST * + opaque clang type *"
      functionality from lldb_private::Type over into ClangASTType.
      
      llvm-svn: 109046
      e1a916a7
  8. Jul 21, 2010
  9. Jul 09, 2010
  10. Jul 07, 2010
  11. Jun 08, 2010
Loading