Add two initial settings for the PlatformDarwinKernel plugin,
plugin.platform.darwin-kernel.search-locally-for-kexts [true|false]
plugin.platform.darwin-kernel.kext-directories [directory list]
llvm-svn: 178846
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
LLDB now can use a single dash for all long options for all commands form the command line and from the command interpreter. This involved just switching all calls from getopt_long() to getopt_long_only().
llvm-svn: 178789
Make lldb_private::RegularExpression thread safe everywhere. This was done by removing the m_matches array from the lldb_private::RegularExpression class and putting it into the new lldb_private::RegularExpression::Match class. When executing a regular expression you now have the option to create a lldb_private::RegularExpression::Match object and pass a pointer in if you want to get parenthesized matching. If you don't want any matching, you pass in NULL. The lldb_private::RegularExpression::Match object is initialized with the number of matches you desire. Any matching strings are now extracted from the lldb_private::RegularExpression::Match objects. This makes the regular expression objects thread safe and as a result many more regex objects were turned into static objects that end up using a local lldb_private::RegularExpression::Match object when executing.
llvm-svn: 178702
Symbol table function names should support lookups like symbols with debug info.
To fix this I:
- Gutted the way FindFunctions is used, there used to be way too much smarts only in the DWARF plug-in
- Made it more efficient by chopping the name up once and using simpler queries so that SymbolFile and Symtab plug-ins don't need to do as much
- Filter the results at a higher level
- Make the lldb_private::Symtab able to chop up C++ mangled names and make as much sense out of them as possible and also be able to search by basename, fullname, method name, and selector name.
llvm-svn: 178608
Reimplemented the NSDictionary synthetic children provider for added performance.
Instead of generating pairs by running an expression, we now create a pair type using clang-level APIs and fill in a buffer with the pointers to key and value
This strategy takes the time required to dump a 10k items __NSDictionaryM from ~45s to <4s
llvm-svn: 178601
ASTContexts that will not stay around. Before, we
did this in a very half-hearted way. Now we maintain
work queues of all Decls that need to be completed
before the source ASTContext can go away; we then
expunge their origins completely.
<rdar://problem/13511875>
llvm-svn: 178410
PC relative loads are missing disassembly comments when disassembled in a live process.
This issue was because some sections, like __TEXT and __DATA in libobjc.A.dylib, were being moved when they were put into the dyld shared cache. This could also affect any other system that slides sections individually.
The solution is to keep track of wether the bytes we will disassemble are from an executable file (file address), or from a live process (load address). We now do the right thing based off of this input in all cases.
llvm-svn: 178315
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
With this notion, if parties outside the ScriptInterpreter itself need to acquire a lock on script APIs, they can do so by a pattern like this:
{
auto lock = interpeter->AcquireInterpreterLock();
// do whatever you need to do...
} // lock will automatically be released here
This might be useful for classes that use the Python convenience objects (e.g. PythonDictionary) to ensure they keep the underlying interpreter in a safe and controlled condition while they call through the C API functions
Of course, the ScriptInterpreter still manages its internal locking correctly when necessary :-)
llvm-svn: 178189
- Making an error message more consistent
- Ensuring the element size is not zero before using it in a modulus
- Properly using target settings to cap the std::list element count
- Removing spurious element size calculations that were unused
- Removing spurious capping in std::map
llvm-svn: 178057
ValueObjects themselves use DumpValueObjectOptions as the currency for the same purpose
The code to convert between these two units was replicated (to varying degrees of correctness) in several spots in the code
This checkin provides one and only one (and hopefully correct :-) entry point for this conversion
llvm-svn: 178044
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
Jason Molenda