Fixed templates with NonTypeTemplateParmDecl objects. For example:
template <unsigned N>
....
This fixes SmallVector and all of the other classes that have template params
that are non types.
llvm-svn: 145667
will allow us to represent a process/thread ID using a pointer for the OS
plug-ins where they might want to represent the process or thread ID using
the address of the process or thread structure.
llvm-svn: 145644
in the face of failures to import types, since blithely
passing on NULL types can sometimes lead to trouble.
Also eliminated a use of getAs and replaced it with
dyn_cast, which is more robust.
llvm-svn: 145628
enhancements. With these enhancements, the return values
of Objective-C methods with unknown return types can be
implicitly cast to id for the purpose of making method
calls.
So what would have required this:
(int)[(id)[ClassWithNoDebugInfo methodReturningObject] methodReturningInt]
can now be written as:
(int)[[ClassWithNoDebugInfo methodReturningObject] methodReturningInt]
llvm-svn: 145567
robust:
- Now a client can specify what kind of symbols
are needed; notably, this allows looking up
Objective-C class symbols specifically.
- In the class of symbols being looked up, if
one is non-NULL and others are NULL, LLDB now
prefers the non-NULL one.
llvm-svn: 145554
ClangASTSource::~ClangASTSource() was calling
ClangASTContext *scratch_clang_ast_context = m_target->GetScratchClangASTContext();
which had the side effect of deleting this very ClangASTSource instance. Not good.
Change it to
// We are in the process of destruction, don't create clang ast context on demand
// by passing false to Target::GetScratchClangASTContext(create_on_demand).
ClangASTContext *scratch_clang_ast_context = m_target->GetScratchClangASTContext(false);
The Target::GetScratchClangASTContext(bool create_on_demand=true) has a new signature.
llvm-svn: 145537
to find Objective-C class types by looking in the
symbol tables for the individual object files.
I did this as follows:
- I added code to SymbolFileSymtab that vends
Clang types for symbols matching the pattern
"_OBJC_CLASS_$_NSMyClassName," making them
appear as Objective-C classes. This only occurs
in modules that do not have debug information,
since otherwise SymbolFileDWARF would be in
charge of looking up types.
- I made a new SymbolVendor subclass for the
Apple Objective-C runtime that is in charge of
making global lookups of Objective-C types. It
currently just sends out type lookup requests to
the appropriate SymbolFiles, but in the future we
will probably extend it to query the runtime more
completely.
I also modified a testcase whose behavior is changed
by the fact that we now actually return an Objective-C
type for __NSCFString.
llvm-svn: 145526
Fix wrong test logic in test_modules_search_paths(). Add additional exercising of 'target modules search-paths list/query".
There is a reproducible crash if 'target modules search-paths clear' is exercised during test teardown.
So we currently comment out the stmt as follows:
# Add teardown hook to clear image-search-paths after the test.
# rdar://problem/10501020
# Uncomment the following to reproduce 10501020.
#self.addTearDownHook(lambda: self.runCmd("target modules search-paths clear"))
llvm-svn: 145466
Fixed an issue where if we are debugging on a remote platform and set a
platform path for our executable, it was not being honored by the new
launch functions that used the ProcessLaunchInfo.
llvm-svn: 145371
as well as attached a new priority description as to why and when you would
want to implement each packet.
Also documented the additions we have made to the stop reply packet and why
the extra information is necessary.
llvm-svn: 145357
management of what allocations remain after an
expression finishes executing. This saves around
2.5KiB per expression for simple expressions.
llvm-svn: 145342
so that we can do Python scripting like this:
target = self.dbg.CreateTarget(self.exe)
self.dbg.SetAsync(True)
process = target.LaunchSimple(None, None, os.getcwd())
process.PutSTDIN("Line 1 Entered.\n")
process.PutSTDIN("Line 2 Entered.\n")
process.PutSTDIN("Line 3 Entered.\n")
Add TestProcessIO.py to exercise the process IO API: PutSTDIN()/GetSTDOUT()/GetSTDERR().
llvm-svn: 145282
to launch a process for debugging. Since this isn't supported on all platforms,
we need to do what we used to do if this isn't supported. I added:
bool
Platform::CanDebugProcess ();
This will get checked before trying to launch a process for debugging and then
fall back to launching the process through the current host debugger. This
should solve the issue for linux and keep the platform code clean.
Centralized logging code for logging errors, warnings and logs when reporting
things for modules or symbol files. Both lldb_private::Module and
lldb_private::SymbolFile now have the following member functions:
void
LogMessage (Log *log, const char *format, ...);
void
ReportWarning (const char *format, ...);
void
ReportError (const char *format, ...);
These will all output the module name and object (if any) such as:
"error: lldb.so ...."
"warning: my_archive.a(foo.o) ...."
This will keep the output consistent and stop a lot of logging calls from
having to try and output all of the information that uniquely identifies
a module or symbol file. Many places in the code were grabbing the path to the
object file manually and if the module represented a .o file in an archive, we
would see log messages like:
error: foo.a - some error happened
llvm-svn: 145219
to 30% of memory. The size doubling was killing us and we ended up with up to
just under 50% of empty capacity. Cleaning this up saves us a ton of memory.
llvm-svn: 145086
Fixed an issue with the options for memory read where --count couldn't be used
with the --binary option when writing data to a file.
Also removed the GDB format option from the --binary version of memory read.
llvm-svn: 145067
something like "display/4i $pc" (or something like this). With LLDB we already
were showing 3 lines of source before and 3 lines of source after the current
source line when showing a stop context. We now improve this by allowing the
user to control the number of lines with the new "stop-line-count-before" and
"stop-line-count-after" settings. Also, there is a new setting for how many
disassembly lines to show: "stop-disassembly-count". This will control how many
source lines are shown when there is no source or when we have no source line
info.
settings set stop-line-count-before 3
settings set stop-line-count-after 3
settings set stop-disassembly-count 4
settings set stop-disassembly-display no-source
The default values are set as shown above and allow 3 lines of source before
and after (what we used to do) the current stop location, and will display 4
lines of disassembly if the source is not available or if we have no debug
info. If both "stop-source-context-before" and "stop-source-context-after" are
set to zero, this will disable showing any source when stopped. The
"stop-disassembly-display" setting is an enumeration that allows you to control
when to display disassembly. It has 3 possible values:
"never" - never show disassembly no matter what
"no-source" - only show disassembly when there is no source line info or the source files are missing
"always" - always show disassembly.
llvm-svn: 145050
Sean Callanan