user process dyld binary and/or a mach kernel binary image. By
default, it prefers the kernel if it finds both.
But if it finds two kernel binary images (which can happen when
random things are mapped into memory), it may pick the wrong
kernel image.
DynamicLoaderDarwinKernel has heuristics to find a kernel in memory;
once we've established that there is a kernel binary in memory,
call over to that class to see if it can find a kernel address via
its search methods. If it does, use that.
Some minor cleanups to DynamicLoaderDarwinKernel while I was at it.
<rdar://problem/24446112>
llvm-svn: 259983
Obviously, if the original Debugger goes away, those commands are holding on to now stale memory, which has the potential to cause crashes
Fixes rdar://24460882
llvm-svn: 259964
This patch adds logic to detect if underlying binary is using arm hard float abi and use that information while handling return values in ABISysV_arm.
Differential revision: http://reviews.llvm.org/D16627
llvm-svn: 259885
Summary:
This reverts commit 8af14b5f9af68c31ac80945e5b5d56f0a14b38e4.
Reverting as it breaks a few tests on Mac.
Reviewers: spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16895
llvm-svn: 259823
GetName actually got the queue name not the thread name and anyway didn't actually work to do
that. So I just deleted it with a fixme.
<rdar://problem/24487554>
llvm-svn: 259818
Summary:
While evaluating expressions when stopped in a class method, there was a
problem of member variables hiding local variables. This was happening
because, in the context of a method, clang already knew about member
variables with their name and assumed that they were the only variables
with those names in scope. Consequently, clang never checks with LLDB
about the possibility of local variables with the same name and goes
wrong. This change addresses the problem by using an artificial
namespace "$__lldb_local_vars". All local variables in scope are
declared in the "$__lldb_expr" method as follows:
using $__lldb_local_vars::<local var 1>;
using $__lldb_local_vars::<local var 2>;
...
This hides the member variables with the same name and forces clang to
enquire about the variables which it thinks are declared in
$__lldb_local_vars. When LLDB notices that clang is enquiring about
variables in $__lldb_local_vars, it looks up local vars and conveys
their information if found. This way, member variables do not hide local
variables, leading to correct evaluation of expressions.
A point to keep in mind is that the above solution does not solve the
problem for one specific case:
namespace N
{
int a;
}
class A
{
public:
void Method();
int a;
};
void
A::Method()
{
using N::a;
...
// Since the above solution only touches locals, it does not
// force clang to enquire about "a" coming from namespace N.
}
Reviewers: clayborg, spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16746
llvm-svn: 259810
This doesn't attempt to move every decorator. The reason for
this is that it requires touching every single test file to import
decorators.py. I would like to do this in a followup patch, but
in the interest of keeping the patches as bite-sized as possible,
I've only attempted to move the underlying common decorators first.
A few tests call these directly, so those tests are updated as part
of this patch.
llvm-svn: 259807
previously, I have marked only one test as flaky, but now I noticed another test failing with the
same error. I am going to assume all of them are flaky.
llvm-svn: 259775
Summary:
gdb-remote tests are not able to use the same logging mechanisms as the rest of our tests, and
currently we get no host logs from them, even though the tests themselves have logging
capability. This commit changes that. When user specifies that he would like to log the
gdb-remote channel (--channel gdb-remote argument to dotest.py), we write detailed logs to the
<TEST_ID>-host.log file, just like we would in the case of regular tests. If this argument is not
specified, we only log the serious messages to stderr, which matches the existing behaviour.
Reviewers: tfiala, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16858
llvm-svn: 259774
Patch replaces the --refresh flag removed in r258800 with it's own command, 'language renderscript allocation refresh'.
Since there is no reason this functionality should be tied to another command as an option.
The command itself simply re-JITs all our cached information about allocations.
llvm-svn: 259773
reason to None when we stop due to a trace, then noticed that
we were on a breakpoint that was not valid for the current thread.
That should actually have set it back to trace.
This was pr26441 (<rdar://problem/24470203>)
llvm-svn: 259684
My eventual goal is to move all of the test decorators to their
own module such as `decorators.py`. But some of the decorators
use existing functions in `lldbtest.py` and conceptually the
functions are probably more appropriately placed in lldbplatformutil.
Moreover, lldbtest.py is a huge file with a ton of random utility
functions scattered around, so this patch also workds toward the
goal of reducing the footprint of this one module to a more
reasonable size.
So this patch moves some of them over to lldbplatformutil with the
eventual goal of moving decorators over to their own module.
Reviewed By: Tamas Berghammer, Pavel Labath
Differential Revision: http://reviews.llvm.org/D16830
llvm-svn: 259680
Runtimes should be able to pass custom compilation options to the JIT for their stack frame. This patch adds a custom expression options member class to LanguageOptions, and modifies the clang expression evaluator to check the current runtime for those options. If those options are available on the runtime, they are passed to the clang compiler.
Committed for Luke Drummond.
Differential Revision: http://reviews.llvm.org/D15527
llvm-svn: 259644
This decorator was used in only one test, and it's behaviour was quite complicated. It skipped
if:
- test was remote
- platform was *not* android
I am not aware of anyone running tests with this configuration (and even then, I am not aware of
a reason why the test should not pass), but if TestLoadUnload starts breaking for you after this
commit, please disable the test with
@expectedFailureAll(remote=True, oslist=[YOUR_PLATFORM])
llvm-svn: 259642
65535 is still a valid port. This should fix the android failures we were getting when we chose
to connect over 65535 to the remote lldb-server.
llvm-svn: 259638
A DWARF language vender extension for RenderScript was added to LLVM in r259348(http://reviews.llvm.org/D16409)
We should use this generated enum instead of the hardcoded value.
RenderScript is also based on C99 with some extensions, so we want to use ClangASTContext when RS is detected.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16766
llvm-svn: 259634
track a source for. When we are pushing breakpoints and stepping past function prologues,
also push past code from line 0 immediately following the prologue end.
<rdar://problem/23730696>
llvm-svn: 259611
I don't understand how this worked before, but this fixes the recent test regressions on Windows in TestConsecutiveBreakpoints.py.
Differential Revision: http://reviews.llvm.org/D16825
llvm-svn: 259605
Previously we were returning a tuple of (bool, skip_reason) from
the tuple function. This makes for some awkward code, especially
since a value of True for the first argument implies that the
second argument is None, and a value of False implies that the
second argument is not None. So it was basically redundant, and
with this patch we simply return the skip reason or None directly.
llvm-svn: 259590
This should be no functional change, just a refactoring of the
skip decorators to all centralize on a single function,
`skipTestIfFn` that does all the logic. This allows easier
maintenance of the decorators and also centralizes all the
hard-to-understand logic in one place.
Reviewed by: Pavel Labath
Differential Revision: http://reviews.llvm.org/D16741
llvm-svn: 259543
The file contained very similar 4 implementation of the same data
structure with a lot of duplicated code and some minor API differences.
This CL refactor the class to eliminate the duplicated codes and to
unify the APIs.
RangeMap.h also contained a class called AddressDataArray what have very
little added functionality over an std::vector and used only by
ObjectFileMacO The CL moves the class to ObjectFileMachO.cpp as it isn't
belongs into RangeMap.h and shouldn't be used in new places anyway
because of the little added functionality.
Differential revision: http://reviews.llvm.org/D16769
llvm-svn: 259538
After recent changes, test_thread_state_is_stopped has become equivalent to test_step_in, as the
function exit_during_step_base was not using the "test_thread_state" parameter. As test was
XFAILed on all platforms anyway, and we have other tests for the bug which it (used to) test, I
am simply removing the function.
llvm-svn: 259517
The ARM instruction emulator had 2 bugs related to the handling of the
IT instruction causing an error in single stepping:
* We haven't initialized the IT mask from the CPSR so if the last
instruction of the IT block is a branch and the condition is false
then the emulator evaluated the branch what resulted in an incorrect
pc for the next instruction.
* The ITSTATE was advanced before the execution of each instruction. As
a result the emulator was using the condition of following instruction
in every case. The ITSTATE should be edvanced after the execution of
an instruction except after an IT instruction.
Differential revision: http://reviews.llvm.org/D16772
llvm-svn: 259509
Summary:
r259344 introduced a bug, where we fail to perform a single step, when the instruction we are
stepping onto contains a breakpoint which is not valid for this thread. This fixes the problem
and add a test case.
Reviewers: tberghammer, emaste
Subscribers: abhishek.aggarwal, lldb-commits, emaste
Differential Revision: http://reviews.llvm.org/D16767
llvm-svn: 259488
r259433 introduced a regression, where if a compiler is specified without a path (e.g., CC=clang,
relying on the fact that clang is in $PATH), then the test suite would fail (at the compiler
version detection step) because realpath would interpret this as a path relative to cwd). The fix
is to perform the $PATH expansion (via `which`) before the realpath step.
llvm-svn: 259484
Jason Molenda