Simplify the logging on ObjectFile::~ObjectFile() to not access an classes above the object file (like the module) so we don't crash when logging object lifetimes. The log message contains the "this" pointer value which can be matched up with the constructor log.
llvm-svn: 168754
DebugClang builds of LLDB to build a properly
codesigned debugserver. I did this by adding
a DebugClang configuration to debugserver that's
just a clone of the Debug configuration.
llvm-svn: 168746
Make sure that ValueObjectDynamicValue clears itself when no dynamic type information can be found
This behavior was supposed to be already happening (as per the comment lines)
llvm-svn: 168743
Allow the expression parser to see more than just data symbols. We now accept any symbol that has an address. We take precautions to only accept symbols by their mangled or demangled names only if the demangled name was not synthesized. If the demangled name is synthesized, then we now mark symbols accordingly and only compare against the mangled original name.
llvm-svn: 168668
- use lldb settings command instead of os.environ
- use dyldPath fixture variable instead of hardcoding LD_LIBRARY_PATH
- add tear-down hook to restore environment after testcase is run
llvm-svn: 168613
- use lldb 'settings' command to help testcase find shared library
- pull up dyldPath variable from TestLoadUnload.py to fixture base class (applicable in multiple cases)
llvm-svn: 168612
- Handle EINVAL return code from ptrace(GETSIGINFO, ...): not an error, but 'group-stop' state on Linux
- propagate SIGSTOP to inferior in above case
- this commit resolves the failure in expression_command/timeout testcase
Thanks to Sean Callanan & Matt Kopec for helping debug this problem
llvm-svn: 168523
- missing includes in cpp test programs
- mismatched dwarf/dsym test cases
- make "com.apple.main-thread" expected string conditional on darwin platform
llvm-svn: 168452
allowed volatile registers to be returned up the stack. That leads
to unexpected/incorrect values provided to the user and we need to
avoid that.
<rdar://problem/12714247>
llvm-svn: 168123
Fixed an issue where lldb was setting breakpoints on too many methods when a partial function name with namespaces or class qualifiers was used. For example setting a breakpoint of "Foo::dealloc" was accidentally settings breakpoints on all objective C functions whose selector was "dealloc"...
llvm-svn: 168053
expressions that refer to ivars will not work because Clang
emits IR that refers to them to get the ivar offsets.
However, it is possible to search the runtime for these values.
I have added support for reading the relevant tables to the
Objective-C runtime, and extended ClangExpressionDeclMap to
query that information if and only if it doesn't find the symbols
in the binary.
Also added a testcase.
<rdar://problem/12628122>
llvm-svn: 168018
When uniquing classes against one another we can't depend on any or all of the artificial functions (default ctor, dtor, copy ctor, move ctor, etc) being in each definition. Now we treat those separately and handle those to the best of our ability.
llvm-svn: 167752
GCD queue names of threads to
ProcessGDBRemote::GetDispatchQueueNameForThread()
May need tweaking once this version is rolled out but visual
inspection looks fine.
<rdar://problem/12333100>
llvm-svn: 167667
Solving an issue where "command script import" would fail to pick the file indicated by the user as a result of something with the same name being in an earlier position in sys.path
llvm-svn: 167570
This commit does three things:
(a) introduces a new notification model for adding/removing/changing modules to a ModuleList, and applies it to the Target's ModuleList, so that we make sure to always trigger the right set of actions
whenever modules come and go in a target. Certain spots in the code still need to "manually" notify the Target for several reasons, so this is a work in progress
(b) adds a new capability to the Platforms: locating a scripting resources associated to a module. A scripting resource is a Python file that can load commands, formatters, ... and any other action
of interest corresponding to the loading of a module. At the moment, this is only implemented on Mac OS X and only for files inside .dSYM bundles - the next step is going to be letting
the frameworks themselves hold their scripting resources. Implementors of platforms for other systems are free to implement "the right thing" for their own worlds
(c) hooking up items (a) and (b) so that targets auto-load the scripting resources as the corresponding modules get loaded in a target. This has a few caveats at the moment:
- the user needs to manually add the .py file to the dSYM (soon, it will also work in the framework itself)
- if two modules with the same name show up during the lifetime of an LLDB session, the second one won't be able to load its scripting resource, but will otherwise work just fine
llvm-svn: 167569
DynamicLoaderDarwinKernel::OSKextLoadedKextSummary::LoadImageUsingMemoryModule
where it assumed that a kernel had been found in memory, when that may not be
the case when we're attaching to a device early in the boot process.
<rdar://problem/12638140>
llvm-svn: 167564
<rdar://problem/12153915> (partial fix)
Remove an assert and place an error message instead so we don't crash when we run into a type tag that we don't recognize. We will now emit a warning so that hopefully we can get a bug report that has example code that shows what we are missing.
Also fixed a case when trying to unique one type to another where we would confuse concrete instances of methods with their definitions and end up not correctly registering the types.
llvm-svn: 167557
x/9i
we actually calculated the size of 9 instructions. Then we multiplied it by the count again
to get the total amount we should fetch, so we thought 9 x86_64 instructions took over 1K
to fetch...
<rdar://problem/12649027>
llvm-svn: 167520
Also fixed a bug where the Objective-C runtime
would not properly report that it found a class if
(a) it had to build the ObjCInterfaceDecl for the
class and (b) logging was enabled.
<rdar://problem/12641180>
llvm-svn: 167516
Unnamed bitfields cause struct layout problems
Synthesize unnamed bitfields when required. Most compilers don't mention unnamed bitfields in the DWARF, so we need to create them to keep clang happy with the types we create from the DWARF. We currently can't do this for ObjC since the DW_AT_bit_offset value for any direct ivars of ObjC classes as the values for these attributes are bogus. A bug has been filed on Clang to fix this, and another bug has been filed on LLDB to make sure we fix the DWARF parser once the clang fix is in by looking the the DW_AT_producer in the compile unit attributes and finding the compiler version and only enabling it for newer versions of clang.
llvm-svn: 167424
- make sure to delet the .cer file on the desktop
- added section that describes what to do when you re-install a new OS where
you still have an old code signing certificate around.
llvm-svn: 167389
The operator== method is a synonym for IsExactMatch().
The essential difference between these two is that IsCompatibleMatch()
will say that armv7 and armv7s are compatible and return true.
IsExactMatch() will say that armv7 and armv7s are not a match.
An armv7s cpu can run either generic armv7 binaries or armv7s binaries
(the latter being tuned for it). When we're picking the slice of a
universal Mach-O file to load in an armv7s Target, we need to be able to
first look for an exact cpu subtype match (armv7s == armv7s) and failing
that, looking for a slice with a compatible architecture.
Update ObjectContainerUniversalMachO::GetObjectFile to prefer an exact
match of the cpu type, falling back to a compatible match if necessary.
<rdar://problem/12593515>
llvm-svn: 167365
the resolved version of the rhs FileSpec's directory name with the lhs FileSpec's directory name. We really meant to compare it
with the rhs FileSpec's directory name...
<rdar://problem/12438838>
llvm-svn: 167349
the runtime if we have complete debug information
for a class.
Also made the Objective-C language runtime return
NULL when asked for the complete debug information
(i.e., information from DWARF, not information from
the runtime) if that information isn't present. It
used to return a non-authoritative version, which
made it hard for clients to determine whether
complete debug information was available.
<rdar://problem/12608895>
llvm-svn: 167299
statements instead of a switch for the size of the floating
point types; some architectures sizeof double and sizeof long
double are the same and that's invalid in a switch.
Fix the LLDB_DISABLE_PYTHON ifdef block in FormatManager::LoadObjCFormatters
so it builds on arm again.
llvm-svn: 167263
LLDB now provides base class offsets (virtual and non virtual) to Clang's record layout. We previously were told this wasn't necessary, but it is when pragma pack gets involved.
llvm-svn: 167262
and silence the backtrace printout
In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly
instead of having the default behavior
llvm-svn: 167067
RegisterContextKDP_i386 was not correctly writing registers due to missing "virtual" keywords. Added the virtual keywords and made the functions pure virtual to ensure subclasses can't get away without implementing these functions.
llvm-svn: 167066
"~rc" via getpwnam() instead of doing tilde expansion and doing soft-link
dereferencing via realpath() - if we're pointing to a softlink, leave it
as-is.
<rdar://problem/12597698>
llvm-svn: 167052
The attached patch adds eValueTypeVector to lldb_private::Value. The nested struct Vector is patterned after RegisterValue::m_data.buffer. This change to Value allows ClangExpressionDeclMap::LookupDecl to return vector register data for consumption by InterpreterStackFrame::ResolveValue. Note that ResolveValue was tweaked slightly to allocate enough memory for vector registers.
An immediate result of this patch is that "expr $xmm0" generates the same results on Linux as on the Mac, which is good enough for TestRegisters.py. In addition, the log of m_memory.PrintData(data_region.m_base, data_region.m_extent) shows that the register content has been resolved successfully. On the other hand, the output is glaringly empty:
runCmd: expr $xmm0
output: (unsigned char __attribute__((ext_vector_type(16)))) $0 = {}
Expecting sub string: vector_type
Matched
llvm-svn: 167033
There should be no functional changes as SBData creation functions already checked for NULL regardless of size - but it ensures consistency
llvm-svn: 166978
This should delay initialization of Python until strictly necessary and speed-up debugger startup
Also, convert formatters for SEL and BOOL ObjC data-types from Python to C++, in order to reap more performance benefits from the above changes
llvm-svn: 166967
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
Removing the IsDynamic() and GetStaticValue() calls, so that they will default to the base class behavior:
- non-dynamic
- itself as the static value
This is in contrast with the previous behavior which could be confusing and could potentially cause issues when using those objects
llvm-svn: 166857
- 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
The subtle behavior is that the Predicate wait functions may not detect transitory changes in the predicate value. Consider the following scenario.
Thread A waits for a bit to be set in the predicate value.
Thread B sets the bit in the predicate value.
Before Thread A wakes up, Thread C clears the bit in the predicate value.
Thread A wakes, checks the value and goes back to waiting.
The mutex and condition variables protect access to the value, but they offer no guarantee that another thread will not acquire the mutex and change the value before a waiting thread is restarted after a change.
I believe that the current behavior is correct and reasonable. I just want to leave a marker to prevent possible problems in the future or to help anyone who might be unfortunate enough to encounter such a problem.
llvm-svn: 166800
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
Changed all relevant test cases to verify that MightHaveChildren() works correctly for objects of interest
Added a bunch of convenience methods for test cases to use: target(), process(), thread() and frame() which mimic the lldb.X convenience variables
As a bonus, edited the documentation on the website to describe the new method available for synthetic children providers writers to implement!
That's all folks!
llvm-svn: 166535
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
Remove 'Customization', 'Documentation', and 'FAQ' pages from the sidebar's "USE AND EXTENSION"
section. These pages have no content. If someone ever wants to add content to them, we can
re-add them to the sidebar.
llvm-svn: 166380
Daniel Malea