I tracked down a leak that could happen when detaching from a process where the lldb_private::Process objects would stay around forever. This was caused by a eStateDetached event that was queued up on the lldb_private::Process private state thread listener. Since process events contain shared pointers to the process, this is dangerous if they don't get consume or cleared as having the lldb_private::Process class contain a collection of things that have a shared pointer to yourself is obviously bad.
To fix this I modified the Process::Finalize() function to clear this list. The actual thing that was holding onto the ModuleSP and thus the static archive, was a stack frame. Since the process wasn't going away, it still had thread objects and they still had frames. I modified the Thread::Destroy() to clear the stack frames to ensure this further doesn't happen.
llvm-svn: 166964
so it could hold this information, and then used it to look up unfound names in the object pointer
if it exists. This gets "frame var" to work for unqualified references to ivars captured in blocks.
But the expression parser is ignoring this information still.
llvm-svn: 166860
- Only read the statically-defined isa table in the
shared cache once. Only the dynamically-constructed
isa table can change.
- Ignore the statically-defined isa table if its
version isn't what we expect.
llvm-svn: 166856
Full UnwindPlan is trying to do an impossible unwind; in that case
invalidate the Full UnwindPlan and replace it with the architecture
default unwind plan.
This is a scenario that happens occasionally with arm unwinds in
particular; the instruction analysis based full unwindplan can
mis-parse the functions and the stack walk stops prematurely. Now
we can do a simpleminded frame-chain walk to find the caller frame
and continue the unwind. It's not ideal but given the complicated
nature of analyzing the arm functions, and the lack of eh_frame
information on iOS, it is a distinct improvement and fixes some
long-standing problems with the unwinder on that platform.
This is fixing <rdar://problem/12091421>. I may re-use this
invalidate feature in the future if I can identify other cases where
the full unwindplan's unwind information is clearly incorrect.
This checkin also includes some cleanup for the volatile register
definition in the arm ABI plugin for <rdar://problem/10652166>
although work remains to be done for that bug.
llvm-svn: 166757
the function's prologue instructions so we can re-instate that prologue
if we hit an early return mid-function. Add some additional heuristics
to differentiate between prologue and epilogue instruction sequences.
This fixes the specific problem of correctly unwinding through a function
which has an epilogue one instruction after the last prologue setup
instruction has completed.
<rdar://problem/12091139>
llvm-svn: 166465
- Fixed a crash when the executable module
couldn't be found.
- Fixed a problem that made it impossible
to attach to processes in the simulator
using the SBTarget::Attach.
llvm-svn: 166355
Added commands to the KDP plug-in that allow sending raw commands through the KDP protocol. You specify a command byte and a payload as ASCII hex bytes, and the packet is created with a valid header/sequenceID/length and sent. The command responds with a raw ASCII hex string that contains all bytes in the reply including the header.
An example of sending a read register packet for the GPR on x86_64:
(lldb) process plugin packet send --command 0x07 --payload 0100000004000000
llvm-svn: 166346
plugin
dynamic-loader
macosx-kernel
(bool) disable-kext-loading
To settings can be set using:
(lldb) settings set plugin.dynamic-loader.macosx-kernel.disable-kext-loading true
I currently only hooked up the DynamicLoader plug-ins, but the code is very easy to duplicate when and if we need settings for other plug-ins.
llvm-svn: 166294
1 by the expression parser. We now correctly
report that they are of size 0. (C++ structs
are mandated to have nonzero size, and Clang marks
them as being 1 byte in size.)
<rdar://problem/12380800>
llvm-svn: 166256
Added a new setting that allows a python OS plug-in to detect threads and provide registers for memory threads. To enable this you set the setting:
settings set target.process.python-os-plugin-path lldb/examples/python/operating_system.py
Then run your program and see the extra threads.
llvm-svn: 166244
<rdar://problem/12068650>
More fixes to how we handle paths that are used to create a target.
This modification centralizes the location where and how what the user specifies gets resolved. Prior to this fix, the TargetList::CreateTarget variants took a FileSpec object which meant everyone had the opportunity to resolve the path their own way. Now both CreateTarget variants take a "const char *use_exe_path" which allows the TargetList::CreateTarget to centralize where the resolving happens and "do the right thing".
llvm-svn: 166186
to handle an addition class of early-return instructions we find in arm code:
tail-call optimziation returns where we restore the register state from the
function entry and jump directly (not branch & link) to another function --
when that other function returns, it will return to our caller.
Previously this mid-function epilogue sequence was not being correctly detected.
We would not re-instate the prologue setup instructions for the rest of the function
so unwinds would break from that point until the end of the function.
<rdar://problem/12502597>
llvm-svn: 166081
This patch fixes an issue where if lldb fails to attach to a process (ie. invalid pid) on Linux, the process monitor thread gets stuck waiting for a signal from the attach thread, which never comes due to not being signaled. It also implements StopOpThread which is used for both attach/launch cases as I'm not aware of any special handling needed for the attach case. Also, propagate 'Error' from the Detach function instead of using a bool.
llvm-svn: 166055
must push something on the stack for a function call or not. In
x86, the stack pointer is decremented when the caller's pc is saved
on the stack. In arm, the stack pointer and frame pointer don't
necessarily have to change for a function call, although most
functions need to use some stack space during their execution.
Use this information in the RegisterContextLLDB to detect invalid
unwind scenarios more accurately.
<rdar://problem/12348574>
llvm-svn: 166005
I added the ability for a process plug-in to implement custom commands. All the lldb_private::Process plug-in has to do is override:
virtual CommandObject *
GetPluginCommandObject();
This object returned should be a multi-word command that vends LLDB commands. There is a sample implementation in ProcessGDBRemote that is hollowed out. It is intended to be used for sending a custom packet, though the body of the command execute function has yet to be implemented!
llvm-svn: 165861
Dynamic type code must be efficient and fast. Now it is.
Added ObjC v1 support for getting the complete list of ISA values.
The main flow of the AppleObjCRuntime subclasses is now they must override "virtual bool UpdateISAToDescriptorMap_Impl();". This function will update the complete list of ISA values and create ClassDescriptorSP objects for each one. Now we have the complete list of valid ISA values which we can use for verification when doing dynamic typing.
Refactored a bunch of stuff so that the AppleObjCRuntime subclasses don't have to implement as many functions as they used to.
llvm-svn: 165730
Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame
changes the stack.
Made the Driver use this notification to print the new thread status rather than doing it in the command.
Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call.
<rdar://problem/12383087>
llvm-svn: 165640
over to simply update its cache and then look up
the descriptor in the cache. This is fine because
the cache now builds much faster (since descriptors
are minimal).
Metaclasses aren't in the cache, so I switched
the Describe method for class descriptors from using
GetClassDescriptor to manually creating an automatic
ClassDescriptorV2.
llvm-svn: 165579
The following are now derived lazily:
- The name of the class (cached);
- the instance size of the class (not cached);
The following have been removed entirely:
- Whether the class is realized. This is an
implementation detail.
- The contents of the objc_class object. That
object can be read as needed.
- Whether the class is valid. The fact that
we vended a class to begin with means it's
valid. We will only give up looking parts
of it up if they are not in the format we
expect.
llvm-svn: 165567
lighter-weight so that the cache can be populated
faster.
- I Added a ProcessWP to the runtime so I can
take it out of the individual descriptors, saving
space;
- I made the constructors for the descriptors
private so that only the runtime can invoke them;
and
- I removed the constructor that takes a ValueObject
since the logic for using a ValueObject is in the
runtime.
llvm-svn: 165549
whether we try to call an external program to load symbols unconditionally,
or if we check the user's preferences before calling it.
ProcessMachCore now sets CanJIT to false - we can't execute code in a core file.
DynamicLoaderDarwinKernel::OSKextLoadedKextSummary::LoadImageUsingMemoryModule changed
to load the kernel from an on-disk file if at all possible.
Don't load the kext binaries out of memory from the remote systems - their linkedit doesn't
seem to be in a good state and we'll error out down in SymbolVendorMacOSX if we try to use
the in-memory images.
Call Symbols::DownloadObjectAndSymbolFile to get the kext/kernel binary -- the external
program may be able to give us a file path on the local filesystem instead of reading
the binary / dSYM over a network drive every time. Fall back to calling
Target::GetSharedModule() like before if DownloadObjectAndSymbolFile fails.
llvm-svn: 165471
if we have a kernel binary, set the target's architecture to match.
Include the target's architecture in the ModuleSpec when we're searching for the
kext binaries on the local system -- otherwise we won't get a specific slice of
a fat file picked out for us and we won't use the returned Module correctly.
Remove the redundant attempt to find a file on the local filesystem from this method.
In ProcessGDBRemote::CheckForKernel(), if we have a kernel binary in memory, mark
the canJIT as false. There is no jitting code in kernel debug sessions.
llvm-svn: 165357
enabled after we'd found a few bugs that were caused by shadowed
local variables; the most important issue this turned up was
a common mistake of trying to obtain a mutex lock for the scope
of a code block by doing
Mutex::Locker(m_map_mutex);
This doesn't assign the lock object to a local variable; it is
a temporary that has its dtor called immediately. Instead,
Mutex::Locker locker(m_map_mutex);
does what is intended. For some reason -Wshadow happened to
highlight these as shadowed variables.
I also fixed a few obivous and easy shadowed variable issues
across the code base but there are a couple dozen more that
should be fixed when someone has a free minute.
<rdar://problem/12437585>
llvm-svn: 165269
remove the duplicates of this code in ProcessGDBRemote and ProcessKDP.
These two Process plugins will hardcode their DynamicLoader name to be
the DynamicLoaderDarwinKernel so the correct DynamicLoader is picked,
and return the kernel load address as the ImageInfosAddress.
<rdar://problem/12417038>
llvm-svn: 165080
the Symbols::LocateExecutableObjectFile method to locate kexts and
kernels instead of copying them out of the memory of the remote
system. This is the fix for <rdar://problem/12416384>.
Fix a variable shadowing problem in
Symbols::LocateMacOSXFilesUsingDebugSymbols which caused the symbol
rich executable binaries to not be found even if they were listed
in the dSYM Info.plist.
Change Symbols::DownloadObjectAndSymbolFile to ignore dsymForUUID's
negative cache - this is typically being called by the user and we
should try even if there's a incorrect entry in the negative cache.
llvm-svn: 165061
When attaching to a remote system that does not look like a typical vendor system, and no
executable binary was specified to lldb, check a couple of fixed locations where kernels
running in ASLR mode (slid in memory to a random address) store their load addr when booted
in debug mode, and relocate the symbols or load the kernel wholesale from the host computer
if we can find it.
<rdar://problem/7714201>
llvm-svn: 164888
loaded at a random offset).
To get the kernel's UUID and load address I need to send a kdp
packet so I had to implement the kernel relocation (and attempt to
find the kernel if none was provided to lldb already) in ProcessKDP
-- but this code really properly belongs in DynamicLoaderDarwinKernel.
I also had to add an optional Stream to ConnectRemote so
ProcessKDP::DoConnectRemote can print feedback about the remote kernel's
UUID, load address, and notify the user if we auto-loaded the kernel via
the UUID.
<rdar://problem/7714201>
llvm-svn: 164881
runtime, we read method signatures for both class
and instance methods out of the runtime data.
(lldb) fr var str
(NSString *) str = 0x0000000105000180 @"Hello from '/Volumes/Data/projects/lldb/test/lang/objc/foundation/a.out'"
(lldb) expr str.length
(unsigned long long) $0 = 72
(lldb) expr [NSString stringWithCString:"Hello world!" encoding:1]
(id) $1 = 0x0000000105100050
(lldb) po $1
$1 = 0x0000000105100050 Hello world!
(lldb) fr var array1
(NSArray *) array1 = 0x000000010010a6e0 @"3 objects"
(lldb) expr array1.count
(unsigned long long) $0 = 3
(lldb) expr [array1 objectAtIndex:2]
(id) $1 = 0x00000001000025d0
(lldb) po $1
$1 = 0x00000001000025d0 array1 object3
Notice that both regular and property-style notation
work. I still need to add explicit support for
properties with non-default setters/getters.
This information is only queried if an Objective-C
object does not have debug information for a complete
type available. Otherwise we query debug information
as usual.
llvm-svn: 164878
top-of-tree. Removed all local patches and llvm.zip.
The intent is that fron now on top-of-tree will
always build against LLVM/Clang top-of-tree, and
that problems building will be resolved as they
occur. Stable release branches of LLDB can be
constructed as needed and linked to specific release
branches of LLVM/Clang.
llvm-svn: 164563
where the descriptor took a pointer to an object and
expected the Initialize function to dereference that
pointer and extract the isa value. This caused one
of our tests to fail.
llvm-svn: 164353
KDP -- now with rudimentary process control (continue only) and read + write registers (which means we can see stack frames) for x86_64, i386 and ARM.
llvm-svn: 164352
We can now read the relevant data structures for
the method list, and use a callback mechanism to
report their details to the AppleObjCTypeVendor,
which constructs appropriate Clang types.
llvm-svn: 164310
data structures more rapidly. Also added fields
for the other data structures in a class.
I also fixed a problem where I accidentally used
hasExternalLexicalStorage() instead of
hasExternalVisibleStorage() to mark an
incomplete object.
llvm-svn: 164197
populate Clang ObjCInterfaceDecls with their
ivars, methods, and properties. The default
implementation does nothing. I have also made
sure that AppleObjCRuntimeV2 creates
ObjCInterfaceDecls that actually get queried
appropriately.
llvm-svn: 164164
the dynamic and static runtime class tables to
construct our isa table. This is putting the runtime
in contact with unrealized classes, which we need
to deal with in order to get accurate information.
That's the next piece of work.
<rdar://problem/10986023>
llvm-svn: 163957
Partial fix for the above radar where we now resolve dsym mach-o files within the dSYM bundle when using "add-dsym" through the platform.
llvm-svn: 163676
information from the Objective-C runtime.
This patch takes the old AppleObjCSymbolVendor and
replaces it with an AppleObjCTypeVendor, which is
much more lightweight. Specifically, the SymbolVendor
needs to pretend that there is a backing symbol file
for the Types it vends, whereas a TypeVendor only
vends bare ClangASTTypes. These ClangASTTypes only
need to exist in an ASTContext.
The ClangASTSource now falls back to the runtime's
TypeVendor (if one exists) if the debug information
doesn't find a complete type for a particular
Objective-C interface. The runtime's TypeVendor
maintains an ASTContext full of types it knows about,
and re-uses the ISA-based type query information used
by the ValueObjects.
Currently, the runtime's TypeVendor doesn't provide
useful answers because we haven't yet implemented a
way to iterate across all ISAs contained in the target
process's runtime. That's the next step.
llvm-svn: 163651
it is unconditionally present now.
ObjectContainerBSDArchive::CreateInstance %z8.8x is not a valid printf arg specifier, %8.8zx would work
for size_t arg but this arg is addr_t. use %8.8llx and cast up to uint64_t.
ObjectFile::FindPlugin ditto.
DynamicRegisterInfo::SetRegisterInfo ifdef this function out if LLDB_DISABLE_PYTHON.
llvm-svn: 163599
The attached patch fixes a problem with performing an attach from the SBTarget API on Linux (and other systems that use ProcessPOSIX).
When Process::Attach was called from SBTarget, it resulted in a call to a form of the DoAttachWithID function that wasn't implemented in ProcessPOSIX, and so it fell back to the default implementation (which just returns an error). It didn't seem necessary to use the attach_info parameter for this case, so I just implemented it as a call to the simpler version of the function.
In debugging this problem, I also found that SBTarget wasn't checking the return value from the Attach call, causing it to hang when the attach fails.
llvm-svn: 163399
Jim Ingham