Summary:
TestExprsChar.py
Char is unsigned char by default in PowerPC.
TestDisassembleBreakpoint.py
Modify disassemble testcase to consider multiple architectures.
TestThreadJump.py
Jumping directly to the return line on PowerPC architecture dos not
means returning the value that is seen on the code. The last test fails,
because it needs the execution of some assembly in the beginning of the
function. Avoiding this test for this architecture.
TestEhFrameUnwind.py
Implement func for ppc64le test case.
TestWatchLocation.py
TestStepOverWatchpoint.py
PowerPC currently supports only one H/W watchpoint.
TestDisassembleRawData.py
Add PowerPC opcode and instruction for disassemble testcase.
Reviewers: labath
Reviewed By: labath
Subscribers: davide, labath, alexandreyy, lldb-commits, luporl, lbianc
Differential Revision: https://reviews.llvm.org/D44472
Patch by Alexandre Yukio Yamashita <alexandre.yamashita@eldorado.org.br>.
llvm-svn: 328488
running watchos. These tests cannot run on normal customer devices,
but I hope to some day have a public facing bot running against a
device.
llvm-svn: 314355
Normal customer devices won't be able to run these tests, we're hoping to get
a public facing bot set up at some point. Both devices pass the testsuite without
any errors or failures.
I have seen some instability with the armv7 test runs, I may submit additional patches
to address this. arm64 looks good.
I'll be watching the bots for the rest of today; if any problems are introduced by
this patch I'll revert it - if anyone sees a problem with their bot that I don't
see, please do the same. I know it's a rather large patch.
One change I had to make specifically for iOS devices was that debugserver can't
create files. There were several tests that launch the inferior process redirecting
its output to a file, then they retrieve the file. They were not trying to test
file redirection in these tests, so I rewrote those to write their output to a file
directly.
llvm-svn: 314132
Normal customer devices won't be able to run these devices, we're hoping to get
a public facing bot set up at some point. Both devices pass the testsuite without
any errors or failures.
I have seen some instability with the armv7 test runs, I may submit additional patches
to address this. arm64 looks good.
I'll be watching the bots for the rest of today; if any problems are introduced by
this patch I'll revert it - if anyone sees a problem with their bot that I don't
see, please do the same. I know it's a rather large patch.
One change I had to make specifically for iOS devices was that debugserver can't
create files. There were several tests that launch the inferior process redirecting
its output to a file, then they retrieve the file. They were not trying to test
file redirection in these tests, so I rewrote those to write their output to a file
directly.
llvm-svn: 314038
Normal customer devices won't be able to run these devices, we're hoping to get
a public facing bot set up at some point.
There will be some smaller follow-on patches. The changes to tools/lldb-server are
verbose and I'm not thrilled with having to skip all of these tests manually.
There are a few places where I'm making the assumption that "armv7", "armv7k", "arm64"
means it's an ios device, and I need to review & clean these up with an OS check
as well. (Android will show up as "arm" and "aarch64" so by pure luck they shouldn't
cause problems, but it's not an assumption I want to rely on).
I'll be watching the bots for the rest of today; if any problems are introduced by
this patch I'll revert it - if anyone sees a problem with their bot that I don't
see, please do the same. I know it's a rather large patch.
One change I had to make specifically for iOS devices was that debugserver can't
create files. There were several tests that launch the inferior process redirecting
its output to a file, then they retrieve the file. They were not trying to test
file redirection in these tests, so I rewrote those to write their output to a file
directly.
llvm-svn: 313932
I was over-eager to unable this test in r304976. It still fails in this
combination, at there does not seem to be anything we can do about it,
as the generated code does not preserve the link register.
llvm-svn: 305062
Summary:
When a call instruction is the last instruction in a function, the
backtrace PC will point past the end of the function. We already had
special code to handle that, but we did not handle the case where the PC
ends up outside of the bounds of the module containing the function,
which is a situation that occured in TestNoreturnUnwind on android for
some arch/compiler combinations.
I fix this by adding an argument to Address resolution code which states
that we are ok with addresses pointing to the end of a module/section to
resolve to that module/section.
I create a reproducible test case for this situation by hand-crafting an
executable which has a noreturn function at the end of a module.
Reviewers: jasonmolenda, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32022
llvm-svn: 304976
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
Summary:
The issue arises due to the wrong unwinder used for the first
stack frame, where the default unwinder returns erroneous frame
whereas the fallback would have given the correct frame had it
been used.
The following fix consists of two parts ->
1) The first part changes the unwinding strategy, earlier the
default unwinder was used to get 2 more stack frames and if it
failed a fallback unwinder was used. Now we try to obtain as many
frames (max 10) as we can get from default unwinder and also
fallback unwinder and use the one that gives more number of frames.
2) Normally unwindplans are assosciated with functions and the
row to be used is obtained from the offset (obtained from the low_pc
of the function symbol). Sometimes it may occur that the unwindplan
is assosciated to the complete Elf section in which case the offset
calculation would be wrong as the debugger uses the same offset originally
obtained from the function symbol. Hence this offset is recalculated.
Reviewers: tberghammer, lldb-commits, labath, jasonmolenda
Subscribers: jingham
Differential Revision: http://reviews.llvm.org/D21221
llvm-svn: 274750
Summary:
The issue arises because LLDB is not
able to read the vdso library correctly.
The fix adds memory allocation callbacks
to allocate sufficient memory in case the
requested offsets don't fit in the memory
buffer allocated for the ELF.
Reviewers: lldb-commits, clayborg, deepak2427, ovyalov, labath, tberghammer
Differential Revision: http://reviews.llvm.org/D16107
llvm-svn: 258122
Summary:
The testcase TestNoreturnUnwind.py was failing
because the unwind from the vdso library was not
successful for clang compiler while it was passing
for gcc. It was passing for gcc since the unwind plan
used was the assembly plan and the ebp register was
set by the main function in case of gcc and was not
used by the functions in the call flow to the vdso, whereas
clang did not emit assembly prologue for main and so
the assembly unwind was failing. Normally in case of
failure of assembly unwind, lldb switches to EH CFI frame
based unwinding, but this was not happening for
the first frame. This patch tries to fix this behaviour by
falling to EH CFI frame based unwinding in case of assembly
unwind failure even for the first frame.
The test is still marked as XFAIL since it relys on the fix
of another bug.
Reviewers: lldb-commits, jingham, zturner, tberghammer, jasonmolenda
Subscribers: jasonmolenda
Differential Revision: http://reviews.llvm.org/D15046
llvm-svn: 257465
This module was originally intended to be imported by top-level
scripts to be able to find the LLDB packages and third party
libraries. Packages themselves shouldn't need to import it,
because by the time it gets into the package, the top-level
script should have already done this. Indeed, it was just
adding the same values to sys.path multiple times, so this
patch is essentially no functional change.
To make sure it doesn't get re-introduced, we also delete the
`use_lldb_suite` module from `lldbsuite/test`, although the
original copy still remains in `lldb/test`
llvm-svn: 251963
For convenience, we had added the folder that dotest.py was in
to sys.path, so that we could easily write things like
`import lldbutil` from anywhere and any test. This introduces
a subtle problem when using Python's package system, because when
unittest2 imports a particular test suite, the test suite is detached
from the package. Thus, writing "import lldbutil" from dotest imports
it as part of the package, and writing the same line from a test
does a fresh import since the importing module was not part of
the same package.
The real way to fix this is to use absolute imports everywhere. Instead
of writing "import lldbutil", we need to write "import
lldbsuite.test.util". This patch fixes up that and all other similar
cases, and additionally removes the script directory from sys.path
to ensure that this can't happen again.
llvm-svn: 251886
This is the conclusion of an effort to get LLDB's Python code
structured into a bona-fide Python package. This has a number
of benefits, but most notably the ability to more easily share
Python code between different but related pieces of LLDB's Python
infrastructure (for example, `scripts` can now share code with
`test`).
llvm-svn: 251532
