Skip to content
  1. Feb 17, 2012
    • Greg Clayton's avatar
      This checking is part one of trying to add some threading safety to our · cc4d0146
      Greg Clayton authored
      internals. The first part of this is to use a new class:
      
      lldb_private::ExecutionContextRef
      
      This class holds onto weak pointers to the target, process, thread and frame
      and it also contains the thread ID and frame Stack ID in case the thread and
      frame objects go away and come back as new objects that represent the same
      logical thread/frame. 
      
      ExecutionContextRef objcets have accessors to access shared pointers for
      the target, process, thread and frame which might return NULL if the backing
      object is no longer available. This allows for references to persistent program
      state without needing to hold a shared pointer to each object and potentially
      keeping that object around for longer than it needs to be. 
      
      You can also "Lock" and ExecutionContextRef (which contains weak pointers)
      object into an ExecutionContext (which contains strong, or shared pointers)
      with code like
      
      ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock());
      
      llvm-svn: 150801
      cc4d0146
  2. Dec 17, 2011
    • Jim Ingham's avatar
      Add the ability to capture the return value in a thread's stop info, and print it · 73ca05a2
      Jim Ingham authored
      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
      73ca05a2
    • Johnny Chen's avatar
      http://llvm.org/bugs/show_bug.cgi?id=11588 · b456b792
      Johnny Chen authored
      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
      b456b792
  3. 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
Loading