DWARFCallFrameInfo method which returns a RangeVector pre-size the
vector based on the number of entries it will be adding insted of
growing the vector as items are added.
llvm-svn: 177773
Clang requires them to have complete types, but
we were previously only completing them if they
were of tag or Objective-C object types.
I have implemented a method on the ASTImporter
whose job is to complete a type. It handles not
only the cases mentioned above, but also array
and atomic types.
<rdar://problem/13446777>
llvm-svn: 177672
This returns a vector of <file address, size> entries for all of
the functions in the module that have an eh_frame FDE.
Update ObjectFileMachO to use the eh_frame FDE function addresses if
the LC_FUNCTION_STARTS section is missing, to fill in the start
addresses of any symbols that have been stripped from the binary.
Generally speaking, lldb works best if it knows the actual start
address of every function in a module - it's especially important
for unwinding, where lldb inspects the instructions in the prologue
of the function. In a stripped binary, it is deprived of this
information and it reduces the quality of our unwinds and saved
register retrieval.
Other ObjectFile users may want to use the function addresses from
DWARFCallFrameInfo to fill in any stripped symbols like ObjectFileMachO
does already.
<rdar://problem/13365659>
llvm-svn: 177624
track the EH FDEs for the functions in a module to using a
RangeDataVector, a more light-weight data structure that only refers
to File addresses. Makes the initial FDE scan about 3x faster, uses
less memory.
<rdar://problem/13465650>
llvm-svn: 177585
of the data it writes down into the process even
if the process doesn't exist. This will allow
the IR interpreter to access static data allocated
on the expression's behalf.
Also cleaned up object ownership in the
IRExecutionUnit so that allocations are created
into the allocations vector. This avoids needless
data copies.
<rdar://problem/13424594>
llvm-svn: 177456
Fixed a crasher in the SourceManager where it wasn't checking the m_target member variable for NULL.
In doing this fix, I hardened this class to have weak pointers to the debugger and target in case they do go away. I also changed SBSourceManager to hold onto weak pointers to the debugger and target so they don't keep objects alive by holding a strong reference to them.
llvm-svn: 177365
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
Variables view out of sync with lldb in Xcode is now fixed. Depending on what happened stack frames could get out of date and a stale shared pointer (one that is no longer a current frame in a thread) could end up being used.
Now we don't store a weak_ptr to a frame in the ExecutionContextRef class, we just store its stack ID and we always regrab the frame from the thread by stack ID.
llvm-svn: 177208
lldb remembers not-found source file, setting target.source-map doesn't make it re-check for it. Now this is fixed. Each time the source path remappings get updated, the modification ID in the PathMappingList gets bumped and then we know the re-check for sources.
llvm-svn: 177125
Made the "--reverse" option to "source list" also be able to use the "--count". This helps us implement support for regexp source list command:
(lldb) l -10
Which gets turned into:
(lldb) source list --reverse --count 10
Also simplified the code that is used to track showing more source from the last file and line.
llvm-svn: 176961
counters for a variety of metrics associated
with expression parsing. This should give some
idea of how much work the expression parser is
doing on Clang's behalf, and help with hopefully
reducing that load over time.
<rdar://problem/13210748> Audit type search/import for expressions
llvm-svn: 176714
Make dynamic type detection faster by using the AST metadata to help out and allow us not to complete types when we don't need to.
After running "purge" on a MacOSX system, the Xcode variables view now populates more than 3x faster with this fix.
llvm-svn: 176676
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
Calculate "can branch" using the MC API's rather than our hand-rolled regex'es.
As extra credit, allow setting the disassembly flavor for x86 based architectures to intel or att.
<rdar://problem/11319574>
<rdar://problem/9329275>
llvm-svn: 176392
and use it to keep from doing the OS Plugin UpdateThreadList while destroying, since
if that does anything that requires the API lock it may deadlock against whoever is
running the Process::Destroy.
<rdar://problem/13308627>
llvm-svn: 176375
StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument.
llvm-svn: 175953
The notion of Crossref command has long been forgotten, and there is nothing using CommandObjectCrossref in the current LLDB codebase
However, this was causing a conflict with process plugins and command aliases ending up in an infinite loop under situations such as:
(lldb) command alias monitor process plugin packet monitor
(lldb) process att -n Calendar
Process 28709 stopped
Executable module set to "/Applications/Calendar.app/Contents/MacOS/Calendar".
Architecture set to: x86_64-apple-macosx.
(lldb) command alias monitor process plugin packet monitor
This fixes the loop (and consequent crash) by disposing of Crossref commands and related code
llvm-svn: 175831
Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp)
This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful
llvm-svn: 175787
Split some NS* formatters in their own source files
Refactored a utility function for the C++ formatters to use
Fixed the skip-summary test case to be explicit about requiring libstdc++ for operation
llvm-svn: 175323
to have it not named appropriately. Also in StopInfoMachException, we aren't testing for software or not software, just
whether the thing is a breakpoint we set. So don't use "software"...
llvm-svn: 175241
Jason Molenda