Skip to content
  1. Apr 11, 2013
    • Sean Callanan's avatar
      Added a Materializer class that contains · 96d2730a
      Sean Callanan authored
      information about each variable that needs to
      be materialized for an expression to work.  The
      next step is to migrate all materialization code
      from ClangExpressionDeclMap to Materializer, and
      to use it for variable materialization.
      
      llvm-svn: 179245
      96d2730a
  2. Apr 05, 2013
    • Sean Callanan's avatar
      Factored out memory access into the target process · 5a1af4e6
      Sean Callanan authored
      from IRExecutionUnit into a superclass called
      IRMemoryMap.  IRMemoryMap handles all reading and
      writing, ensuring that areas are kept track of and
      memory is properly cached (and deleted).
      
      Also fixed several cases where we would simply leak
      binary data in the target process over time.  Now
      the expression objects explicitly own their
      IRExecutionUnit and delete it when they go away.  This
      is why I had to modify ClangUserExpression,
      ClangUtilityFunction, and ClangFunction.
      
      As a side effect of this, I am removing the JIT
      mutex for an IRMemoryMap.  If it turns out that we
      need this mutex, I'll add it in then, but right now
      it's just adding complexity.
      
      This is part of a more general project to make
      expressions fully reusable.  The next step is to
      make materialization and dematerialization use
      the IRMemoryMap API rather than writing and
      reading directly from the process's memory. 
      This will allow the IR interpreter to use the
      same data, but in the host's memory, without having
      to use a different set of pointers.
      
      llvm-svn: 178832
      5a1af4e6
  3. Mar 28, 2013
    • Jim Ingham's avatar
      Use the error from ValidatePlan. · 23460c36
      Jim Ingham authored
      llvm-svn: 178204
      23460c36
    • Greg Clayton's avatar
      <rdar://problem/13521159> · 5160ce5c
      Greg Clayton authored
      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
      5160ce5c
  4. Mar 27, 2013
  5. Mar 19, 2013
    • Sean Callanan's avatar
      Refactored the expression parser so that the IR · 8dfb68e0
      Sean Callanan authored
      and the JITted code are managed by a standalone
      class that handles memory management itself.
      
      I have removed RecordingMemoryManager and
      ProcessDataAllocator, which filled similar roles
      and had confusing ownership, with a common class
      called IRExecutionUnit.  The IRExecutionUnit
      manages all allocations ever made for an expression
      and frees them when it goes away.  It also contains
      the code generator and can vend the Module for an
      expression to other clases.
      
      The end goal here is to make the output of the
      expression parser re-usable; that is, to avoid
      re-parsing when re-parsing isn't necessary.
      
      I've also cleaned up some code and used weak pointers
      in more places.  Please let me know if you see any
      leaks; I checked myself as well but I might have
      missed a case.
      
      llvm-svn: 177364
      8dfb68e0
  6. Feb 09, 2013
  7. Jan 31, 2013
  8. Jan 19, 2013
  9. Jan 15, 2013
    • Jim Ingham's avatar
      Separated the "expr --unwind-on-error" behavior into two parts, actual errors... · 184e9811
      Jim Ingham authored
      Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be
      controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called
      function hits a breakpoint.  For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes
      more sense.  
      Also make both these behaviors globally settable through "settings set".
      Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint.  We were recursing
      and crashing.  Now we just stop without calling the second command.
      
      <rdar://problem/12986644>
      <rdar://problem/9119325>
      
      llvm-svn: 172503
      184e9811
  10. Dec 07, 2012
  11. Dec 06, 2012
  12. Dec 01, 2012
  13. Nov 29, 2012
  14. Oct 31, 2012
  15. Oct 16, 2012
  16. Oct 12, 2012
  17. Sep 18, 2012
  18. Aug 29, 2012
    • Greg Clayton's avatar
      <rdar://problem/11757916> · 1f746071
      Greg Clayton authored
      Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
      - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". 
      - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
      - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
      - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
      
      Cleaned up header includes a bit as well.
      
      llvm-svn: 162860
      1f746071
  19. Aug 18, 2012
  20. Aug 09, 2012
  21. Jul 17, 2012
  22. Jul 14, 2012
  23. Jul 13, 2012
  24. Apr 03, 2012
  25. Mar 01, 2012
  26. Feb 24, 2012
    • Greg Clayton's avatar
      <rdar://problem/10103468> · e72dfb32
      Greg Clayton authored
      I started work on being able to add symbol files after a debug session
      had started with a new "target symfile add" command and quickly ran into
      problems with stale Address objects in breakpoint locations that had 
      lldb_private::Section pointers into modules that had been removed or 
      replaced. This also let to grabbing stale modules from those sections. 
      So I needed to thread harded the Address, Section and related objects.
      
      To do this I modified the ModuleChild class to now require a ModuleSP
      on initialization so that a weak reference can created. I also changed
      all places that were handing out "Section *" to have them hand out SectionSP.
      All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild
      so all of the find plug-in, static creation function and constructors now
      require ModuleSP references instead of Module *. 
      
      Address objects now have weak references to their sections which can
      safely go stale when a module gets destructed. 
      
      This checkin doesn't complete the "target symfile add" command, but it
      does get us a lot clioser to being able to do such things without a high
      risk of crashing or memory corruption.
      
      llvm-svn: 151336
      e72dfb32
  27. Feb 10, 2012
    • Sean Callanan's avatar
      Fixed a bunch of ownership problems with the expression · 933693b6
      Sean Callanan authored
      parser.  Specifically:
      
      - ClangUserExpression now keeps weak pointers to the
        structures it needs and then locks them when needed.
        This ensures that they continue to be valid without
        leaking memory if the ClangUserExpression is long
        lived.
      
      - ClangExpressionDeclMap, instead of keeping a pointer
        to an ExecutionContext, now contains an
        ExecutionContext.  This prevents bugs if the pointer
        or its contents somehow become stale.  It also no
        longer requires that ExecutionContexts be passed
        into any function except its initialization function,
        since it can count on the ExecutionContext still
        being around.
      
      There's a lot of room for improvement (specifically,
      ClangExpressionDeclMap should also use weak pointers
      insetad of shared pointers) but this is an important
      first step that codifies assumptions that already
      existed in the code.
      
      llvm-svn: 150217
      933693b6
  28. Feb 08, 2012
  29. Jan 29, 2012
    • Greg Clayton's avatar
      Switching back to using std::tr1::shared_ptr. We originally switched away · e1cd1be6
      Greg Clayton authored
      due to RTTI worries since llvm and clang don't use RTTI, but I was able to 
      switch back with no issues as far as I can tell. Once the RTTI issue wasn't
      an issue, we were looking for a way to properly track weak pointers to objects
      to solve some of the threading issues we have been running into which naturally
      led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared 
      pointer from just a pointer, which is also easily solved using the 
      std::tr1::enable_shared_from_this class. 
      
      The main reason for this move back is so we can start properly having weak
      references to objects. Currently a lldb_private::Thread class has a refrence
      to its parent lldb_private::Process. This doesn't work well when we now hand
      out a SBThread object that contains a shared pointer to a lldb_private::Thread
      as this SBThread can be held onto by external clients and if they end up
      using one of these objects we can easily crash.
      
      So the next task is to start adopting std::tr1::weak_ptr where ever it makes
      sense which we can do with lldb_private::Debugger, lldb_private::Target,
      lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and
      many more objects now that they are no longer using intrusive ref counted
      pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive
      pointers).
      
      llvm-svn: 149207
      e1cd1be6
  30. Jan 06, 2012
  31. Dec 21, 2011
    • Sean Callanan's avatar
      The "desired result type" code in the expression · 20bb3aa5
      Sean Callanan authored
      parser has hitherto been an implementation waiting
      for a use.  I have now tied the '-o' option for
      the expression command -- which indicates that the
      result is an Objective-C object and needs to be
      printed -- to the ExpressionParser, which
      communicates the desired type to Clang.
      
      Now, if the result of an expression is determined
      by an Objective-C method call for which there is
      no type information, that result is implicitly
      cast to id if and only if the -o option is passed
      to the expression command.  (Otherwise if there
      is no explicit cast Clang will issue an error.
      This behavior is identical to what happened before
      r146756.)
      
      Also added a testcase for -o enabled and disabled.
      
      llvm-svn: 147099
      20bb3aa5
  32. Dec 14, 2011
    • Sean Callanan's avatar
      This commit is the result of a general audit of · fc4f2fb0
      Sean Callanan authored
      the expression parser to locate instances where
      dyn_cast<>() and isa<>() are used on types, and
      replace them with getAs<>() as appropriate.
      
      The difference is that dyn_cast<>() and isa<>()
      are essentially LLVM/Clang's equivalent of RTTI
      -- that is, they try to downcast the object and
      return NULL if they cannot -- but getAs<>() can
      traverse typedefs to perform a semantic cast.
      
      llvm-svn: 146537
      fc4f2fb0
  33. Dec 13, 2011
    • Sean Callanan's avatar
      I have modified the part of the code that finds and · d5cc132b
      Sean Callanan authored
      validates the "self," "this," and "_cmd" pointers
      that get passed into expressions.  It used to check
      them aggressively for validity before allowing the
      expression to run as an object method; now, this
      functionality is gated by a bool and off by default.
      
      Now the default is that when LLDB is stopped in a
      method of a class, code entered using "expr" will
      always masquerade as an instance method.  If for
      some reason "self," "this," or "_cmd" is unavailable
      it will be reported as NULL.  This may cause the
      expression to crash if it relies on those pointers,
      but for example getting the addresses of ivars will
      now work as the user would expect.
      
      llvm-svn: 146465
      d5cc132b
  34. Dec 06, 2011
    • Sean Callanan's avatar
      As part of the work to make Objective-C type information · 0eed0d42
      Sean Callanan authored
      from symbols more accessible, I have added a second
      map to the ClangASTImporter: the ObjCInterfaceMetaMap.
      This map keeps track of all type definitions found for
      a particular Objective-C interface, allowing the
      ClangASTSource to refer to all possible sources when
      looking for method definitions.
      
      There is a bug in lookup that I still need to figure out,
      but after that we should be able to report full method
      information for Objective-C classes shown in symbols.
      
      Also fixed some errors I ran into when enabling the maps
      for the persistent type store.  The persistent type store
      previously did not use the ClangASTImporter to import
      types, instead using ASTImporters that got allocated each
      time a type needed copying.  To support the requirements
      of the persistent type store -- namely, that types must be
      copied, completed, and then completely severed from their
      origin in the parser's AST context (which will go away) --
      I added a new function called DeportType which severs all
      these connections.
      
      llvm-svn: 145914
      0eed0d42
  35. Nov 15, 2011
    • Sean Callanan's avatar
      Pulled in a new version of LLVM/Clang to solve a variety · d5c17edb
      Sean Callanan authored
      of problems with Objective-C object completion.  To go
      along with the LLVM/Clang-side fixes, we have a variety
      of Objective-C improvements.
      
      Fixes include:
      
      - It is now possible to run expressions when stopped in
        an Objective-C class method and have "self" act just
        like "self" would act in the class method itself (i.e.,
        [self classMethod] works without casting the return
        type if debug info is present).  To accomplish this,
        the expression masquerades as a class method added by
        a category.
      
      - Objective-C objects can now provide methods and
        properties and methods to Clang on demand (i.e., the
        ASTImporter sets hasExternalVisibleDecls on Objective-C
        interface objects).
      
      - Objective-C built-in types, which had long been a bone
        of contention (should we be using "id"?  "id*"?), are
        now fetched correctly using accessor functions on
        ClangASTContext.  We inhibit searches for them in the
        debug information.
      
      There are also a variety of logging fixes, and I made two
      changes to the test suite:
      
      - Enabled a test case for Objective-C properties in the
        current translation unit.
      
      - Added a test case for calling Objective-C class methods
        when stopped in a class method.
      
      llvm-svn: 144607
      d5c17edb
  36. Nov 08, 2011
    • Jim Ingham's avatar
      Do a better job of detecting when a breakpoint command has set the target... · 0faa43f9
      Jim Ingham authored
      Do a better job of detecting when a breakpoint command has set the target running again (except you have to ignore
      cases where the breakpoint runs expressions, those don't count as really "running again").
      
      llvm-svn: 144064
      0faa43f9
    • Sean Callanan's avatar
      Added a language parameter to the expression parser, · c7b65067
      Sean Callanan authored
      which will in the future allow expressions to be
      compiled as C, C++, and Objective-C instead of the
      current default Objective-C++.  This feature requires
      some additional support from Clang -- specifically, it
      requires reference types in the parser regardless of
      language -- so it is not yet exposed to the user.
      
      llvm-svn: 144042
      c7b65067
  37. Nov 04, 2011
    • Sean Callanan's avatar
      Occasionally LLDB runs into contexts where the · 744756e3
      Sean Callanan authored
      target is stopped in a C++ or Objective-C method
      but the "self" pointer's valid range actually
      doesn't cover the current location.  Before, that
      was confusing Clang to the point where it crashed;
      now, we sanity-check and fall back to pretending
      we're in a C function if "self" or "this" isn't
      available.
      
      llvm-svn: 143676
      744756e3
Loading