Skip to content
  1. Mar 28, 2013
    • 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
  2. Mar 14, 2013
    • Greg Clayton's avatar
      <rdar://problem/13421412> · faac1118
      Greg Clayton authored
      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
      faac1118
  3. Mar 06, 2013
  4. Mar 04, 2013
    • Greg Clayton's avatar
      <rdar://problem/13338643> · 9422dd64
      Greg Clayton authored
      DWARF with .o files now uses 40-60% less memory!
      
      Big fixes include:
      - Change line table internal representation to contain "file addresses". Since each line table is owned by a compile unit that is owned by a module, it makes address translation into lldb_private::Address easy to do when needed.
      - Removed linked address members/methods from lldb_private::Section and lldb_private::Address
      - lldb_private::LineTable can now relink itself using a FileRangeMap to make it easier to re-link line tables in the future
      - Added ObjectFile::ClearSymtab() so that we can get rid of the object file symbol tables after we parse them once since they are not needed and kept memory allocated for no reason
      - Moved the m_sections_ap (std::auto_ptr to section list) and m_symtab_ap (std::auto_ptr to the lldb_private::Symtab) out of each of the ObjectFile subclasses and put it into lldb_private::ObjectFile.
      - Changed how the debug map is parsed and stored to be able to:
          - Lazily parse the debug map for each object file
          - not require the address map for a .o file until debug information is linked for a .o file
      
      llvm-svn: 176454
      9422dd64
  5. Jan 25, 2013
    • Greg Clayton's avatar
      <rdar://problem/13069948> · c7bece56
      Greg Clayton authored
      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
      c7bece56
  6. Nov 29, 2012
  7. Sep 18, 2012
  8. Aug 11, 2012
    • Greg Clayton's avatar
      <rdar://problem/11791234> · 7f4c7430
      Greg Clayton authored
      Remember to copy the address byte size and the byte order when copying data into a DWARF location object, or things will go wrong.
      
      llvm-svn: 161721
      7f4c7430
    • Greg Clayton's avatar
      <rdar://problem/11791234> · 8179bcac
      Greg Clayton authored
      Fixed an issue that could cause references the shared data for an object file to stay around longer than intended and could cause memory bloat when debugging multiple times.
      
      llvm-svn: 161716
      8179bcac
  9. Mar 10, 2012
  10. Jan 06, 2012
    • Sean Callanan's avatar
      Fixed a bug where the DWARF location expression · d1a5e01f
      Sean Callanan authored
      parser was creating malformed resuls.  When the
      location of a variable is computed by reading a
      register and adding an offset, we shouldn't say
      that the variable's value is located in that
      register.  This was confusing the expression
      parser when trying to read a variable captured
      by a block.
      
      llvm-svn: 147668
      d1a5e01f
  11. Jan 04, 2012
    • Greg Clayton's avatar
      <rdar://problem/10507811> · 96c09687
      Greg Clayton authored
      Be better at detecting when DWARF changes and handle this more
      gracefully than asserting and exiting.
      
      Also fixed up a bunch of system calls that weren't properly checking
      for EINTR.
      
      llvm-svn: 147559
      96c09687
  12. Dec 07, 2011
  13. Dec 01, 2011
  14. Nov 13, 2011
    • Greg Clayton's avatar
      <rdar://problem/10338439> · 2fc93eab
      Greg Clayton authored
      This is the actual fix for the above radar where global variables that weren't
      initialized were not being shown correctly when leaving the DWARF in the .o 
      files. Global variables that aren't intialized have symbols in the .o files
      that specify they are undefined and external to the .o file, yet document the
      size of the variable. This allows the compiler to emit a single copy, but makes
      it harder for our DWARF in .o files with the executable having a debug map
      because the symbol for the global in the .o file doesn't exist in a section
      that we can assign a fixed up linked address to, and also the DWARF contains
      an invalid address in the "DW_OP_addr" location (always zero). This means that
      the DWARF is incorrect and actually maps all such global varaibles to the
      first file address in the .o file which is usually the first function. So we
      can fix this in either of two ways: make a new fake section in the .o file
      so that we have a file address in the .o file that we can relink, or fix the 
      the variable as it is created in the .o file DWARF parser and actually give it
      the file address from the executable. Each variable contains a 
      SymbolContextScope, or a single pointer that helps us to recreate where the
      variables came from (which module, file, function, etc). This context helps
      us to resolve any file addresses that might be in the location description of
      the variable by pointing us to which file the file address comes from, so we
      can just replace the SymbolContextScope and also fix up the location, which we
      would have had to do for the other case as well, and update the file address.
      Now globals display correctly.
      
      The above changes made it possible to determine if a variable is a global
      or static variable when parsing DWARF. The DWARF emits a DW_TAG_variable tag
      for each variable (local, global, or static), yet DWARF provides no way for
      us to classify these variables into these categories. We can now detect when
      a variable has a simple address expressions as its location and this will help
      us classify these correctly.
      
      While making the above changes I also noticed that we had two symbol types:
      eSymbolTypeExtern and eSymbolTypeUndefined which mean essentially the same
      thing: the symbol is not defined in the current object file. Symbol objects
      also have a bit that specifies if a symbol is externally visible, so I got
      rid of the eSymbolTypeExtern symbol type and moved all code locations that
      used it to use the eSymbolTypeUndefined type.
       
      
      llvm-svn: 144489
      2fc93eab
  15. Oct 14, 2011
    • Sean Callanan's avatar
      Improved expression logging. Now all calls to · 7dd98126
      Sean Callanan authored
      FindExternalVisibleDecls and FindExternalLexicalDecls
      are marked and given unique IDs, so that all logging
      done as part of their execution can be traced back to
      the proper call.
      
      Also there was some logging that really wasn't helpful
      in most cases so I disabled it unless verbose logging
      (log enable -v lldb expr) is enabled.
      
      llvm-svn: 141987
      7dd98126
  16. Sep 22, 2011
    • Greg Clayton's avatar
      Converted the lldb_private::Process over to use the intrusive · c14ee32d
      Greg Clayton authored
      shared pointers.
      
      Changed the ExecutionContext over to use shared pointers for
      the target, process, thread and frame since these objects can
      easily go away at any time and any object that was holding onto
      an ExecutionContext was running the risk of using a bad object.
      
      Now that the shared pointers for target, process, thread and
      frame are just a single pointer (they all use the instrusive
      shared pointers) the execution context is much safer and still
      the same size. 
      
      Made the shared pointers in the the ExecutionContext class protected
      and made accessors for all of the various ways to get at the pointers,
      references, and shared pointers.
      
      llvm-svn: 140298
      c14ee32d
  17. Sep 20, 2011
  18. Sep 02, 2011
  19. Jul 11, 2011
    • Greg Clayton's avatar
      Added the ability to see block variables when looking up addresses · c749eb89
      Greg Clayton authored
      with the "target modules lookup --address <addr>" command. The variable
      ID's, names, types, location for the address, and declaration is
      displayed.
      
      This can really help with crash logs since we get, on MacOSX at least,
      the registers for the thread that crashed so it is often possible to
      figure out some of the variable contents. 
      
      llvm-svn: 134886
      c749eb89
  20. 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
  21. May 30, 2011
  22. May 09, 2011
    • Greg Clayton's avatar
      While implementing unwind information using UnwindAssemblyInstEmulation I ran · 7349bd90
      Greg Clayton authored
      into some cleanup I have been wanting to do when reading/writing registers.
      Previously all RegisterContext subclasses would need to implement:
      
      virtual bool
      ReadRegisterBytes (uint32_t reg, DataExtractor &data);
      
      virtual bool
      WriteRegisterBytes (uint32_t reg, DataExtractor &data, uint32_t data_offset = 0);
      
      There is now a new class specifically designed to hold register values: 
              lldb_private::RegisterValue
              
      The new register context calls that subclasses must implement are:
      
      virtual bool
      ReadRegister (const RegisterInfo *reg_info, RegisterValue &reg_value) = 0;
      
      virtual bool
      WriteRegister (const RegisterInfo *reg_info, const RegisterValue &reg_value) = 0;
      
      The RegisterValue class must be big enough to handle any register value. The
      class contains an enumeration for the value type, and then a union for the 
      data value. Any integer/float values are stored directly in an appropriate
      host integer/float. Anything bigger is stored in a byte buffer that has a length
      and byte order. The RegisterValue class also knows how to copy register value
      bytes into in a buffer with a specified byte order which can be used to write
      the register value down into memory, and this does the right thing when not
      all bytes from the register values are needed (getting a uint8 from a uint32
      register value..). 
      
      All RegiterContext and other sources have been switched over to using the new
      regiter value class.
      
      llvm-svn: 131096
      7349bd90
  23. Apr 01, 2011
  24. Mar 24, 2011
  25. Mar 20, 2011
    • Greg Clayton's avatar
      Split all of the core of LLDB.framework/lldb.so into a · 7a5388bf
      Greg Clayton authored
      static archive that can be linked against. LLDB.framework/lldb.so
      exports a very controlled API. Splitting the API into a static
      library allows other tools (debugserver for now) to use the power
      of the LLDB debugger core, yet not export it as its API is not
      portable or maintainable. The Host layer and many of the other
      internal only APIs can now be statically linked against.
      
      Now LLDB.framework/lldb.so links against "liblldb-core.a" instead
      of compiling the .o files only for the shared library. This fix
      is only for compiling with Xcode as the Makefile based build already
      does this.
      
      The Xcode projecdt compiler has been changed to LLVM. Anyone using
      Xcode 3 will need to manually change the compiler back to GCC 4.2,
      or update to Xcode 4.
      
      llvm-svn: 127963
      7a5388bf
  26. Feb 01, 2011
  27. Jan 26, 2011
  28. Jan 06, 2011
    • Greg Clayton's avatar
      Fixed issues with RegisterContext classes and the subclasses. There was · 5ccbd294
      Greg Clayton authored
      an issue with the way the UnwindLLDB was handing out RegisterContexts: it
      was making shared pointers to register contexts and then handing out just
      the pointers (which would get put into shared pointers in the thread and
      stack frame classes) and cause double free issues. MallocScribble helped to
      find these issues after I did some other cleanup. To help avoid any
      RegisterContext issue in the future, all code that deals with them now
      returns shared pointers to the register contexts so we don't end up with
      multiple deletions. Also now that the RegisterContext class doesn't require
      a stack frame, we patched a memory leak where a StackFrame object was being
      created and leaked.
      
      Made the RegisterContext class not have a pointer to a StackFrame object as
      one register context class can be used for N inlined stack frames so there is
      not a 1 - 1 mapping. Updates the ExecutionContextScope part of the 
      RegisterContext class to never return a stack frame to indicate this when it
      is asked to recreate the execution context. Now register contexts point to the
      concrete frame using a concrete frame index. Concrete frames are all of the
      frames that are actually formed on the stack of a thread. These concrete frames
      can be turned into one or more user visible frames due to inlining. Each 
      inlined stack frame has the exact same register context (shared via shared
      pointers) as any parent inlined stack frames all the way up to the concrete 
      frame itself.
      
      So now the stack frames and the register contexts should behave much better.
      
      llvm-svn: 122976
      5ccbd294
  29. Nov 29, 2010
  30. 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
  31. 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
  32. Nov 06, 2010
    • Greg Clayton's avatar
      Modified all logging calls to hand out shared pointers to make sure we · 2d4edfbc
      Greg Clayton authored
      don't crash if we disable logging when some code already has a copy of the
      logger. Prior to this fix, logs were handed out as pointers and if they were
      held onto while a log got disabled, then it could cause a crash. Now all logs
      are handed out as shared pointers so this problem shouldn't happen anymore.
      We are also using our new shared pointers that put the shared pointer count
      and the object into the same allocation for a tad better performance.
      
      llvm-svn: 118319
      2d4edfbc
  33. 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
  34. 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
  35. Aug 24, 2010
    • Greg Clayton's avatar
      Got a lot of the kinks worked out in the inline support after debugging more · 9da7bd07
      Greg Clayton authored
      complex inlined examples.
      
      StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()".
      This is because inlined frames will have a PC value that is the same as the 
      concrete frame that owns the inlined frame, yet the code locations for the
      frame can be different. We also need to be able to get the real PC value for
      a given frame so that variables evaluate correctly. To get the actual PC
      value for a frame you can use:
      
          addr_t pc = frame->GetRegisterContext()->GetPC();
      
      Some issues with the StackFrame stomping on its own symbol context were 
      resolved which were causing the information to change for a frame when the
      stack ID was calculated. Also the StackFrame will now correctly store the
      symbol context resolve flags for any extra bits of information that were 
      looked up (if you ask for a block only and you find one, you will alwasy have
      the compile unit and function).
      
      llvm-svn: 111964
      9da7bd07
    • Greg Clayton's avatar
      Added support for inlined stack frames being represented as real stack frames · 1b72fcb7
      Greg Clayton authored
      which is now on by default. Frames are gotten from the unwinder as concrete
      frames, then if inline frames are to be shown, extra information to track
      and reconstruct these frames is cached with each Thread and exanded as needed.
      
      I added an inline height as part of the lldb_private::StackID class, the class
      that helps us uniquely identify stack frames. This allows for two frames to
      shared the same call frame address, yet differ only in inline height.
      
      Fixed setting breakpoint by address to not require addresses to resolve.
      
      A quick example:
      
      % cat main.cpp
      
      % ./build/Debug/lldb test/stl/a.out 
      Current executable set to 'test/stl/a.out' (x86_64).
      (lldb) breakpoint set --address 0x0000000100000d31
      Breakpoint created: 1: address = 0x0000000100000d31, locations = 1
      (lldb) r
      Launching 'a.out'  (x86_64)
      (lldb) Process 38031 Stopped
      * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread
       277   	
       278   	      _CharT*
       279   	      _M_data() const
       280 ->	      { return  _M_dataplus._M_p; }
       281   	
       282   	      _CharT*
       283   	      _M_data(_CharT* __p)
      (lldb) bt
      thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread
        frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280
        frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288
        frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606
        frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414
        frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14
        frame #5: pc = 0x0000000100000d08, where = a.out`start + 52
      
      Each inline frame contains only the variables that they contain and each inlined
      stack frame is treated as a single entity.
      
      llvm-svn: 111877
      1b72fcb7
    • Sean Callanan's avatar
      Refactored ClangExpressionDeclMap to use · 64dfc9a3
      Sean Callanan authored
      ClangExpressionVariables for found external variables
      as well as for struct members, replacing the Tuple
      and StructMember data structures.
      
      llvm-svn: 111859
      64dfc9a3
Loading