Fixed an issue that could cause circular type parsing that will assert and kill LLDB.
Prior to this fix the DWARF parser would always create class types and not start their definitions (for both C++ and ObjC classes) until we were asked to complete the class later. When we had cases like:
class A
{
class B
{
};
};
We would alway try to complete A before specifying "A" as the decl context for B. Turns out we can just start the definition and still not complete the class since we can check the TagDecl::isCompleteDefinition() function. This only works for C++ types. This means we will not be pulling in the full definition of parent classes all the time and should help with our memory consumption and also reduce the amount of debug info we have to parse.
I also reduced redundant code that was checking in a lldb::clang_type_t was a possible C++ dynamic type since it was still completing the type, just to see if it was dynamic. This was fixed in another function that was checking for a type being dynamic as an ObjC or a C++ type, but there was dedicated fucntion for C++ that we missed.
llvm-svn: 153713
Made sure that the root XPC service validate the right before starting the service. The right is created and authenticated by clients (in this case, lldb) and transferred over for validiation.
llvm-svn: 152802
shouldn't compile any of the XPC support code.
Update macosx/Host.mm to use that define.
Add a LLDB_DISABLE_PYTHON ifdef block around a new function in
Core/FormatManager.cpp.
<rdar://problem/10942125>
llvm-svn: 152293
Added a new makefile target to help us with Apple builds where the installhdrs
will copy the headers for the shared library. Prior to this fix, the install
headers directory would contain the unix style paths to all public header
files ("#include lldb/API/SBDefines.h") instead of the fixed up framework
header paths ("#include <LLDB/SBDefines.h>").
llvm-svn: 152253
This fix really needed to happen as a previous fix I had submitted for
calculating symbol sizes made many symbols appear to have zero size since
the function that was calculating the symbol size was calling another function
that would cause the calculation to happen again. This resulted in some symbols
having zero size when they shouldn't. This could then cause infinite stack
traces and many other side affects.
llvm-svn: 152244
This was done in SBTarget:
lldb::SBInstructionList
lldb::SBTarget::ReadInstructions (lldb::SBAddress base_addr, uint32_t count);
Also cleaned up a few files in the LLDB.framework settings.
llvm-svn: 152152
"desktop" - build all binaries with XPC
"desktop_no_xcp" - build all binaries with none of the XPC binaries
"ios" - build all binaries with special iOS install settings.
Bumped the Xcode project build version for lldb-118 and debugserver-169.
llvm-svn: 151740
and also so we don't break them with our code changes.
The _only_ plug-ins that should be #ifdef'ed out and not compiled in LLDB
are those that only work when running natively on the host system.
This fixed bot the PlatformLinux and PlatformFreeBSD build breakages that
were due to ModuleSpec changes.
llvm-svn: 151539
so that we don't break it with code changes.
After doing this I was able to fix the POSIX-DYLD plug-in so that it builds
after recent ModuleSpec changes.
llvm-svn: 151536
Added a dedicated platform for the iOS simulator. This helps us to find the
correct files for a simulator binary before running and helps us select the
right arch (i386 only) for files when we load them.
llvm-svn: 151436
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
to the __PAGEZERO segment on darwin. The dynamic loader now correctly doesn't
slide __PAGEZERO and it also registers it as an invalid region of memory. This
allows us to not make any memory requests from the local or remote debug session
for any addresses in this region. Stepping performance can improve when uninitialized
local variables that point to locations in __PAGEZERO are attempted to be read
from memory as we won't even make the memory read or write request.
llvm-svn: 151128
is not available (LLDB_DISABLE_PYTHON is defined).
Change build-swig-Python.sh to emit an empty LLDBPythonWrap.cpp file if
this build is LLDB_DISABLE_PYTHON.
Change the "Copy to Xcode.app" shell script phase in the lldb.xcodeproj
to only do this copying for Mac native builds.
llvm-svn: 151035
the lldb_private::StackFrame objects hold onto a weak pointer to the thread
object. The lldb_private::StackFrame objects the the most volatile objects
we have as when we are doing single stepping, frames can often get lost or
thrown away, only to be re-created as another object that still refers to the
same frame. We have another bug tracking that. But we need to be able to
have frames no longer be able to get the thread when they are not part of
a thread anymore, and this is the first step (this fix makes that possible
but doesn't implement it yet).
Also changed lldb_private::ExecutionContextScope to return shared pointers to
all objects in the execution context to further thread harden the internals.
llvm-svn: 150871
Adding new API calls to SBValue to be able to retrieve the associated formatters
Some refactoring to FormatNavigator::Get() in order to shrink its size down to more manageable terms (a future, massive, refactoring effort will still be needed)
Test cases added for the above
llvm-svn: 150784
New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association.
This provides SB classes for each of the main object types involved in providing formatter support:
SBTypeCategory
SBTypeFilter
SBTypeFormat
SBTypeSummary
SBTypeSynthetic
plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions
For naming consistency, this patch also renames a lot of formatters-related classes.
Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side.
The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer.
An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes.
Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories.
llvm-svn: 150558
Greg Clayton