There was a generic catch-all type for path arguments
called "eArgTypePath," and a specialized version
called "eArgTypeFilename." It turns out all the
cases where we used eArgTypePath we could have
used Filename or we explicitly meant a directory.
I changed Path to DirectoryName, made it use the
directory completer, and rationalized the uses of
Path.
<rdar://problem/12559915>
llvm-svn: 166533
Adding the new has_children (or MightHaveChildren() in C++) for the existing synthetic children providers
In a few cases, the new call is going to be much more efficient than the previous num_children > 0 check
When the optimization was marginal (e.g. std::vector<>), the choice was to use num_children in order to keep
implementation details in one function instead of duplicating code
Next step is to provide test cases
llvm-svn: 166506
This commit enables the new HasChildren() feature for synthetic children providers
Namely, it hooks up the required bits and pieces so that individual synthetic children providers can implement a new (optional) has_children call
Default implementations have been provided where necessary so that any existing providers continue to work and behave correctly
Next steps are:
2) writing smart implementations of has_children for our providers whenever possible
3) make a test case
llvm-svn: 166495
it to print the old and new values.
Temporarily disable the "out of scope" checking since it didn't work correctly, and was
not what people generally expected watchpoints to be doing.
llvm-svn: 166472
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
Added a new API call to help efficiently determine if a SBValue could have children:
bool
SBValue::MightHaveChildren ();
This is inteneded to be used bui GUI programs that need to show if a SBValue needs a disclosure triangle when displaying a hierarchical type in a tree view without having to complete the type (by calling SBValue::GetNumChildren()) as completing the type is expensive.
llvm-svn: 166460
options:
- added help ("help language") listing the
possible options;
- added the possibility of synonyms for language
names, in this case "ObjC" for "Objective-C";
and
- made matching against language names case
insensitive.
This should improve discoverability.
<rdar://problem/12552359>
llvm-svn: 166457
Fixed a crasher where if an invalid SBTarget was passed to:
lldb::addr_t
SBAddress::GetLoadAddress (const SBTarget &target) const;
We would crash.
llvm-svn: 166439
Given our implementation of ValueObjects we could have a scenario where a ValueObject has a dynamic type of Foo* at one point, and then its dynamic type changes to Bar*
If Bar* has synthetic children enabled, by the time we figure that out, our public API is already vending SBValues wrapping a DynamicVO, instead of a SyntheticVO and there was
no trivial way for us to change the SP inside an SBValue on the fly
This checkin reimplements SBValue in terms of a wrapper, ValueImpl, that allows this substitutions on-the-fly by overriding GetSP() to do The Right Thing (TM)
As an additional bonus, GetNonSyntheticValue() now works, and we can get rid of the ForceDisableSyntheticChildren idiom in ScriptInterpreterPython
Lastly, this checkin makes sure the synthetic VOs get the correct m_value and m_data from their parents (prevented summaries from working in some cases)
llvm-svn: 166426
Allow type searches to specify a type keyword when searching for type. Currently supported type keywords are: struct, class, union, enum, and typedef.
So now you can search for types with a string like "struct foo".
llvm-svn: 166420
- 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
LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings:
target.arg0 (string) =
There is also the program argument that are separate from the first argument that have existed for a while:
target.run-args (arguments) =
When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the:
- resolved executable path
- argv0
- program args
Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision.
llvm-svn: 166137
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
to work properly; when doing bare-boards rom debugging
force the OS to be one of those when initializing llvm.
<rdar://problem/12504138>
llvm-svn: 166057
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
Greg Clayton