| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
to expectedFailureAll to reverse"
This reverts commit r253106.
llvm-svn: 253197
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This diff approaches building the project natively on NetBSD with the autoconf/gmake framework.
Patch by Kamil Rytarowski. Thanks!
Reviewers: emaste, clayborg
Subscribers: tberghammer, joerg, brucem, lldb-commits
Differential Revision: http://reviews.llvm.org/D14531
llvm-svn: 253153
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: pkgsrc (on NetBSD) ships with python2.7-config.
Patch by Kamil Rytarowski. Thanks!
Reviewers: emaste, clayborg
Subscribers: brucem, lldb-commits, joerg
Differential Revision: http://reviews.llvm.org/D14528
llvm-svn: 253152
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This approach is tunable with custom paths for curses library.
It also detects whether there are requirements met.
I make use of it on NetBSD.
Patch by Kamil Rytarowski. Thanks!
Reviewers: clayborg
Subscribers: brucem, joerg, lldb-commits
Differential Revision: http://reviews.llvm.org/D14529
llvm-svn: 253151
|
|
|
|
|
|
| |
This removes a lot of code, which is A Good Thing(TM)
llvm-svn: 253140
|
|
|
|
| |
llvm-svn: 253137
|
|
|
|
|
|
|
|
|
| |
batons, and function pointers, and raw memory allocations instead of safer more modern constructs
This is a first pass at a cleanup of that code, modernizing the "type X clear" commands, and providing the basic infrastructure I plan to use all over
More cleanup will come over the next few days
llvm-svn: 253125
|
|
|
|
| |
llvm-svn: 253113
|
|
|
|
| |
llvm-svn: 253112
|
|
|
|
| |
llvm-svn: 253111
|
|
|
|
| |
llvm-svn: 253110
|
|
|
|
|
|
|
|
| |
expectedFailureAll to reverse
the sense of the test.
llvm-svn: 253106
|
|
|
|
| |
llvm-svn: 253101
|
|
|
|
|
|
|
|
| |
to break on. Rerunning
was being foiled by ASLR.
llvm-svn: 253094
|
|
|
|
| |
llvm-svn: 253093
|
|
|
|
| |
llvm-svn: 253092
|
|
|
|
| |
llvm-svn: 253089
|
|
|
|
| |
llvm-svn: 253088
|
|
|
|
| |
llvm-svn: 253087
|
|
|
|
|
|
|
|
| |
I'm seeing some cases where the ThreadPlan is null. It could
be a sign of a valid race condition, but at least we shouldn't
crash.
llvm-svn: 253086
|
|
|
|
| |
llvm-svn: 253085
|
|
|
|
| |
llvm-svn: 253073
|
|
|
|
| |
llvm-svn: 253057
|
|
|
|
| |
llvm-svn: 253054
|
|
|
|
| |
llvm-svn: 253042
|
|
|
|
|
|
|
| |
these decorators were two of many removed in r253026. Unlike others, these tests still seem to be
failing...
llvm-svn: 253034
|
|
|
|
| |
llvm-svn: 253028
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change Test-rdar-12481949.py to expect GetValueAsUnsigned() to return
0xffffffff if the variable is an int32_t (signed, 4 byte integer) with
value of -1. The previous expectation where we expected the value to be
0xffffffffffffffff doesn't make sense as nothing explains why we would
treat it as an 8 byte value.
This CL also removes a hack from Scalar::ULongLong what was most likely
added to get this test passing as it only worked in case the value of
the variable is -1 and didn't make any sense even in that case.
Differential revision: http://reviews.llvm.org/D14611
llvm-svn: 253027
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Reason of both bugs:
1. For the very first frame, Unwinder doesn't check the validity
of Full UnwindPlan before creating StackFrame from it:
When 'process launch' command is run after setting a breakpoint
in inferior, the Unwinder runs and saves only Frame 0 (the frame
in which breakpoint was set) in thread's StackFrameList i.e.
m_curr_frames_sp. However, it doesn't check the validity of the
Full UnwindPlan for this frame by unwinding 2 more frames further.
2. Unwinder doesn't update the CFA value of Cursor when Full UnwindPlan
fails and FallBack UnwindPlan succeeds in providing valid CFA values
for frames:
Sometimes during unwinding of stack frames, the Full UnwindPlan
inside the RegisterContextLLDB object may fail to provide valid
CFA values for these frames. Then the Fallback UnwindPlan is used
to unwind the frames.
If the Fallback UnwindPlan succeeds, then it provides a valid new
CFA value. The RegisterContextLLDB::m_cfa field of Cursor object
is updated during the Fallback UnwindPlan execution. However,
UnwindLLDB misses the implementation to update the 'cfa' field
of this Cursor with this valid new CFA value.
- This patch fixes both these issues.
- Remove XFAIL in test files corresponding to these 2 Bugs
Change-Id: I932ea407545ceee2d628f946ecc61a4806d4cc86
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: jingham, lldb-commits, jasonmolenda
Subscribers: lldb-commits, ovyalov, tberghammer
Differential Revision: http://reviews.llvm.org/D14226
llvm-svn: 253026
|
|
|
|
|
|
|
|
| |
correctly handle stepping over one breakpoint directly onto another breakpoint.
This isn't fixing that bug, but rather just changing 252963 to not use breakpoints
if it is only stepping one instruction.
llvm-svn: 253008
|
|
|
|
| |
llvm-svn: 253004
|
|
|
|
|
|
|
| |
I forgot to reset the restore flag when calling member function
`Acquire`. The newly added unittest should cover this case.
llvm-svn: 253002
|
|
|
|
| |
llvm-svn: 252998
|
|
|
|
| |
llvm-svn: 252995
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a helper class which supports a number of
features including exception to string formatting with
backtrace handling and auto-restore of exception state
upon scope exit.
Additionally, unit tests are included to verify the
feature set of the class.
llvm-svn: 252994
|
|
|
|
|
|
|
|
| |
This allows other potential unit test suites (of which one is
forthcoming in a subsequent patch) to re-use the same initialization
and teardown of the GIL.
llvm-svn: 252993
|
|
|
|
|
|
|
| |
The latter function, from PythonDataObjects, is Python 3 ready and
the former was not.
llvm-svn: 252992
|
|
|
|
|
|
|
|
|
|
| |
commands are running through a range "
- Revert because this commit introduce several failures in lldb test suite
- http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/8391
- This reverts commit 78943bb678c2893703ee4e8b41969372740c8a6f.
llvm-svn: 252980
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
running through a range
of addresses, and the range has no branches, instead of running to the last instruction and
single-stepping over that, run to the first instruction after the end of the range. If there
are no branches in the current range, then the bytes right after it have to be in the current
function, and have to be instructions not data in code, so this is safe. And it cuts down one
extra stepi per source range step.
Incidentally, this also works around a bug in the llvm Intel assembler where it treats the "rep"
prefix as a separate instruction from the repeated instruction. If that were at the end of a
line range, then we would put a trap in place of the repeated instruction, which is undefined
behavior. Current processors just ignore the repetition in this case, which changes program behavior.
Since there would never be a line range break after the rep prefix, always doing the range stepping
to the beginning of the new range avoids this problem.
<rdar://problem/23461686>
llvm-svn: 252963
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14591
llvm-svn: 252950
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This finishes the effort to port python-wrapper.swig code over to
using PythonDataObjects.
Also included in this patch is the removal of `PyCallable` from
`python-wrapper.swig`, as it is no longer used after having been
replaced by `PythonCallable` everywhere.
There might be additional cleanup as followup patches, but it should
be all fairly simple and minor.
llvm-svn: 252939
|
|
|
|
| |
llvm-svn: 252914
|
|
|
|
| |
llvm-svn: 252909
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PyCallable is a class that exists solely within the swig wrapper
code. PythonCallable is a more generic implementation of the same
idea that can be used by any Python-related interop code, and lives
in PythonDataObjects.h
The CL is mostly mechanical, and it doesn't cover every possible
user of PyCallable, because I want to minimize the impact of this
change (as well as making it easier to figure out what went wrong
in case this causes a failure). I plan to finish up the rest of
the changes in a subsequent patch, culminating in the removal of
PyCallable entirely.
llvm-svn: 252906
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A very expected layout: source tree is in ~/src/llvm, the build directory is in
~/src/llvm-build, and the install location is in /usr/local/{lib,include}.
The DWARF information in /usr/local/lib/libLLVM.a for ilist.h points to
~/src/llvm-build/include/llvm/ADT/ilist.h. Now, when someone includes
"llvm/ADT/ilist.h" and links against /usr/local/lib/libLLVM.a. Disaster.
The DWARF information in libUser.so for ilist.h points to two locations: the one
in /usr/include, and the one in ~/src/llvm-build/include. LLDB gets confused.
Let's uniquify fully-qualified names and never trip on such a thing.
Differential Revision: http://reviews.llvm.org/D14549
llvm-svn: 252898
|
|
|
|
| |
llvm-svn: 252831
|
|
|
|
|
|
|
|
| |
This had been relegated to a simple forwarding function, so just
delete it in preparation of migrating all of these functions out
of python-wrapper.swig.
llvm-svn: 252803
|
|
|
|
|
|
|
|
|
| |
This only begins to port python-wrapper.swig over. Since this
code can be pretty hairy, I plan to do this incrementally over a
series of patches, each time removing or converting more code
over to the PythonDataObjects code.
llvm-svn: 252788
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds PythonTuple and PythonCallable classes to PythonDataObjects.
Additionally, unit tests are provided that exercise this functionality,
including invoking manipulating and checking for validity of tuples,
and invoking and checking for validity of callables using a variety
of different syntaxes.
The goal here is to eventually replace the code in python-wrapper.swig
that directly uses the Python C API to deal with callables and name
resolution with this code that can be more easily tested and debugged.
llvm-svn: 252787
|
|
|
|
| |
llvm-svn: 252767
|