Skip to content
  1. Sep 06, 2011
    • Enrico Granata's avatar
      Redesign of the interaction between Python and frozen objects: · 9128ee2f
      Enrico Granata authored
       - 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
      9128ee2f
  2. Jul 07, 2011
    • Greg Clayton's avatar
      Added "target variable" command that allows introspection of global · 644247c1
      Greg Clayton authored
      variables prior to running your binary. Zero filled sections now get
      section data correctly filled with zeroes when Target::ReadMemory
      reads from the object file section data.
      
      Added new option groups and option values for file lists. I still need
      to hook up all of the options to "target variable" to allow more complete
      introspection by file and shlib.
      
      Added the ability for ValueObjectVariable objects to be created with
      only the target as the execution context. This allows them to be read
      from the object files through Target::ReadMemory(...). 
      
      Added a "virtual Module * GetModule()" function to the ValueObject
      class. By default it will look to the parent variable object and
      return its module. The module is needed when we have global variables
      that have file addresses (virtual addresses that are specific to
      module object files) and in turn allows global variables to be displayed
      prior to running.
      
      Removed all of the unused proxy object support that bit rotted in 
      lldb_private::Value.
      
      Replaced a lot of places that used "FileSpec::Compare (lhs, rhs) == 0" code
      with the more efficient "FileSpec::Equal (lhs, rhs)".
      
      Improved logging in GDB remote plug-in.
      
      llvm-svn: 134579
      644247c1
  3. Jun 30, 2011
    • Greg Clayton's avatar
      Added support for finding and global variables in the SBTarget and SBModule · dea8cb4f
      Greg Clayton authored
      level in the public API. 
      
      Also modified the ValueObject values to be able to display global variables
      without having a valid running process. The globals will read themselves from
      the object file section data if there is no process, and from the process if
      there is one.
      
      Also fixed an issue where modifications for dynamic types could cause child
      values of ValueObjects to not show up if the value was unable to evaluate
      itself (children of NULL pointer objects).
      
      llvm-svn: 134102
      dea8cb4f
  4. May 30, 2011
  5. Apr 23, 2011
  6. Mar 31, 2011
    • Jim Ingham's avatar
      Convert ValueObject to explicitly maintain the Execution Context in which they... · 6035b67d
      Jim Ingham authored
      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
      6035b67d
  7. Feb 15, 2011
  8. Jan 26, 2011
  9. Jan 17, 2011
    • Greg Clayton's avatar
      A few of the issue I have been trying to track down and fix have been due to · 6beaaa68
      Greg Clayton authored
      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
      6beaaa68
  10. Nov 20, 2010
    • Jason Molenda's avatar
      Change the DWARFExpression::Evaluate methods to take an optional · 2d107dd0
      Jason Molenda authored
      RegisterContext* - normally this is retrieved from the ExecutionContext's
      StackFrame but when we need to evaluate an expression while creating
      the stack frame list this can be a little tricky.
      
      Add DW_OP_deref_size, needed for the _sigtramp FDE expression.
      
      Add support for processing DWARF expressions in RegisterContextLLDB.
      
      Update callers to DWARFExpression::Evaluate.
      
      llvm-svn: 119885
      2d107dd0
  11. 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
  12. 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
  13. 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
  14. Sep 28, 2010
  15. Sep 18, 2010
    • Greg Clayton's avatar
      Fixed an issue with: · f5fb427d
      Greg Clayton authored
      (lldb) frame variable --location
      
      Where the address of variables wasn't being formatted consistently.
      
      llvm-svn: 114266
      f5fb427d
  16. Sep 15, 2010
  17. Sep 14, 2010
    • Greg Clayton's avatar
      Looking at some of the test suite failures in DWARF in .o files with the · 016a95eb
      Greg Clayton authored
      debug map showed that the location lists in the .o files needed some 
      refactoring in order to work. The case that was failing was where a function
      that was in the "__TEXT.__textcoal_nt" in the .o file, and in the 
      "__TEXT.__text" section in the main executable. This made symbol lookup fail
      due to the way we were finding a real address in the debug map which was
      by finding the section that the function was in in the .o file and trying to
      find this in the main executable. Now the section list supports finding a
      linked address in a section or any child sections. After fixing this, we ran
      into issue that were due to DWARF and how it represents locations lists. 
      DWARF makes a list of address ranges and expressions that go along with those
      address ranges. The location addresses are expressed in terms of a compile
      unit address + offset. This works fine as long as nothing moves around. When
      stuff moves around and offsets change between the remapped compile unit base
      address and the new function address, then we can run into trouble. To deal
      with this, we now store supply a location list slide amount to any location
      list expressions that will allow us to make the location list addresses into
      zero based offsets from the object that owns the location list (always a
      function in our case). 
      
      With these fixes we can now re-link random address ranges inside the debugger
      for use with our DWARF + debug map, incremental linking, and more.
      
      Another issue that arose when doing the DWARF in the .o files was that GCC
      4.2 emits a ".debug_aranges" that only mentions functions that are externally
      visible. This makes .debug_aranges useless to us and we now generate a real
      address range lookup table in the DWARF parser at the same time as we index
      the name tables (that are needed because .debug_pubnames is just as useless).
      llvm-gcc doesn't generate a .debug_aranges section, though this could be 
      fixed, we aren't going to rely upon it.
      
      Renamed a bunch of "UINT_MAX" to "UINT32_MAX".
      
      llvm-svn: 113829
      016a95eb
  18. Sep 13, 2010
    • Greg Clayton's avatar
      Added a work in the DWARF parser when we parse an array that ends up having · a134cc1b
      Greg Clayton authored
      no elements so that they at least have 1 element. 
      
      Added the ability to show the declaration location of variables to the 
      "frame variables" with the "--show-declaration" option ("-c" for short).
      
      Changed the "frame variables" command over to use the value object code
      so that we use the same code path as the public API does when accessing and
      displaying variable values.
      
      llvm-svn: 113733
      a134cc1b
  19. Sep 02, 2010
    • Greg Clayton's avatar
      StackFrame objects now own ValueObjects for any frame variables (locals, args, · 288bdf9c
      Greg Clayton authored
      function statics, file globals and static variables) that a frame contains. 
      The StackFrame objects can give out ValueObjects instances for
      each variable which allows us to track when a variable changes and doesn't
      depend on variable names when getting value objects.
      
      StackFrame::GetVariableList now takes a boolean to indicate if we want to
      get the frame compile unit globals and static variables.
      
      The value objects in the stack frames can now correctly track when they have
      been modified. There are a few more tweaks needed to complete this work. The
      biggest issue is when stepping creates partial stacks (just frame zero usually)
      and causes previous stack frames not to match up with the current stack frames
      because the previous frames only has frame zero. We don't really want to 
      require that all previous frames be complete since stepping often must check
      stack frames to complete their jobs. I will fix this issue tomorrow.
      
      llvm-svn: 112800
      288bdf9c
  20. Jun 09, 2010
  21. Jun 08, 2010
Loading