Since Unicode support is different in Py2 and Py3, Py3 was throwing
exceptions about being unable to decode the file with the default
encoding.
llvm-svn: 258588
The Windows 10 loader spawns threads at startup, so
tests which count threads or assume that a given user
thread will be at a specific index are incorrect in
this case. The fix here is to use the standard mechanisms
for getting the stopped thread (which is all we are
really interested in anyway) and correlating them with
the breakpoints that were set, and doing checks against
those things.
This fixes about 6 tests on Windows 10.
llvm-svn: 258586
Unfortunately, this turns out not to be working on the lldb-server tests, as there the server is
started in a different way. Since this was a bit of a hack to start with, I am removing it until
I can solve the problem more holistically.
llvm-svn: 258501
Starting with Windows 10, the Windows loader is itself multi-threaded,
meaning that the loader spins up a few threads to do process
initialization before it executes main. Windows delivers these
notifications asynchronously and they can come out of order, so
we can't be sure that the first thread we get a notification about
is actually the zero'th thread.
This patch fixes this by requesting the thread stopped at the
breakpoint that was specified, rather than getting thread 0 and
verifying that it is stopped at a breakpoint.
Differential Revision: http://reviews.llvm.org/D16247
llvm-svn: 258432
Summary:
We already have the ability to collect the server logs when doing local debugging. This enables
the collection of remote logs as well. This relies on specifying a relative path "server.log" for
LLDB_DEBUGSERVER_LOG_FILE when starting remote platform. Since we always set the platform working
directory to a fresh folder to avoid conflicts, the actual file path will always be different and
we can pick the logs up from there.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16322
llvm-svn: 258414
This patch marks some known failures and puts on expectedFailureLinux decorator to have testsuite xfail them.
Affected tests are:
test/functionalities/watchpoint/step_over_watchpoint.py
test/functionalities/watchpoint/watchpoint_set_command/TestWatchLocationWithWatchSet.py
test/tools/lldb-server/TestGdbRemoteSingleStep.py
test/tools/lldb-server/TestGdbRemote_vCont.py
llvm-svn: 258315
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
TestHelloWorld seems to be passing now as far as I can tell. TestExitDuringStep is still hanging.
I have marked the relevant tests as flaky, which should handle the timeouts now as well. I'll be
monitoring the buildbots for fallout.
llvm-svn: 258114
This does not work and causes the class to be silently skipped, which is a bad idea. This makes
sure it cannot happen accidentaly. I've played with the idea of actually making the decorator
work at class level, but it proved too magic to do at this moment.
llvm-svn: 258048
TestConcurrentEvents was marked with a XFAIL decorator at class level, which actually does not
work, and causes the class to be silently skipped everywhere. It seems that making it work at
class level is quite a difficult task, so I will just move it to the individual test methods. I
will follow this up with a commit which makes the decorator blow up in case someone tries to
apply it to a class in the future.
llvm-svn: 257901
There were a number of problems preventing this from working:
1. The SWIG typemaps for converting Python lists to and from C++
arrays were not updated for Python 3. So they were doing things
like PyString_Check instead of using the PythonString from
PythonDataObjects.
2. ProcessLauncherWindows was ignoring the environment completely.
So any test that involved launching an inferior with any kind
of environment variable would have failed.
3. The test itself was using process.GetSTDOUT(), which isn't
implemented on Windows. So this was changed to save the
value of the environment variable in a local variable and
have the debugger look at the value of the variable.
llvm-svn: 257669
The system can create threads for a system threadpool, so there is
no guarantee that the thread that is stopped is thread 1. So use
a more robust check.
llvm-svn: 257513
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
Updated expectedFailureLinux decorator to reflect architecture
Marked some triaged failures as xfails on arm with updated expectedFailureLinux decorator
Differential revision: http://reviews.llvm.org/D15893
llvm-svn: 257405
-gsplit-dwarf is not implemented by clang on Windows. As such,
all the dwo tests are having the -gsplit-dwarf command line option
completely ignored, and the result is you get regular dwarf debug
information, and it's just running the exact same tests twice,
doubling the length of the test suite for no good reason.
llvm-svn: 257363
Summary:
Similar to rL256704 and rL256707, fix a few text files which were
accidentally checked in with DOS line endings, or mixed line endings.
Reviewers: jingham, emaste
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16027
llvm-svn: 257361
The test hangs/crashes/fails because it does not use the listener API in a way that LLDB expects.
I don't really know if this is the fault of LLDB of the test...
llvm-svn: 257323
Summary:
On linux we need the process to give us special permissions before we can attach to it.
Previously, the code for this was copied into every file that needed it. This moves the code to a
central place to reduce code duplication.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15992
llvm-svn: 257319
I prefer to use "-p" over using line_number and then setting by line because it's makes it possible
to see what the breakpoint is at the site where you make the breakpoint. So I switched
it back to -p but specified the source file as well, which is an "all within lldb" way of doing
what Pavel's fix did.
llvm-svn: 257235
