The explicit APIs on SBValue obviously remain if one wants to be explicit in intent, or override this guess, but since __int__() has to pick one, an educated guess is definitely better than than always going to signed regardless
Fixes rdar://24556976
llvm-svn: 260349
CFLAGS is now being set correctly to pass -flimit-debug-info or
-fno-limit-debug-info on FreeBSD. I'm not sure which change is
responsible for the fix, though.
llvm.org/pr25626
llvm-svn: 260330
This removes the following decorators:
* skipIfI386
* expectedFailureI386
* expectedFailurex86_64
* skipIfArch
* skipUnlessArch
* skipUnlessI386
And other related decorators. All code using those decorators
is updated to use expectedFailureAll and skipIf
llvm-svn: 260178
* Change the `not_in` function to be called `no_match`. This makes
it clear that keyword arguments can be more than just lists.
* Change the name of `_check_list_or_lambda` to
`_match_decorator_property`. Again clarifying that decorator params
are not always lists.
* Always use a regex match when matching strings. This allows automatic
support for regex matching on all decorator properties. Also support
compiled regex values.
* Fix a bug in the compiler check used by _decorateTest. The two
arguments were reversed, the condition was always wrong.
* Change one test that uses skipUnlessArch to use skipIf, to
demonstrate that skipIf can now handle more scenarios.
Differential Revision: http://reviews.llvm.org/D16938
llvm-svn: 260135
expectedFailureWindows is equivalent to using the general
expectedFailureAll decorator with oslist="windows". Additionally,
by moving towards these common decorators we can solve the issue
of having to support decorators that can be called with or without
arguments. Once all decorators are always called with arguments,
and this is enforced by design (because you can't specify the condition
you're decorating for without passing an argument) the implementation
of the decorators can become much simpler
Differential Revision: http://reviews.llvm.org/D16936
llvm-svn: 260134
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
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
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
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
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
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
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
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
Summary:
Checks using the result of getCompiler() will fail to identify the compiler
correctly if CC is a symlink path (ie /usr/bin/cc).
Reviewers: zturner, emaste
Subscribers: llvm-commits, sas
Differential Revision: http://reviews.llvm.org/D16488
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 259433
This patch attempts to solve the Python 2 / Python 3 incompatibilities by
introducing a new `encoded_file` abstraction that we use instead of
`io.open()`. The problem with the builtin implementation of `io.open` is
that `read` and `write` accept and return `unicode` objects, which are not
always convenient to work with in Python 2. We solve this by making
`encoded_file.open()` return the same object returned by `io.open()` but
with hooked `read()` and `write()` methods. These hooked methods will
accept binary or text data, and conditionally convert what it gets to a
`unicode` object using the correct encoding. When calling `read()` it
also does any conversion necessary to convert the output back into the
native `string` type of the running python version.
Differential Revision: http://reviews.llvm.org/D16736
llvm-svn: 259379
Summary:
- The patch solves Bug 23478 and Bug 19311. Resolving
Bug 23478 also resolves Bug 23039.
Correct ThreadStopInfo is set for Linux and FreeBSD
platforms.
- Summary:
When a trace event is reported, we need to check
whether the trace event lands at a breakpoint site.
If it lands at a breakpoint site then set the thread's
StopInfo with the reason 'breakpoint'. Else, set the reason
to be 'Trace'.
Change-Id: I0af9765e782fd74bc0cead41548486009f8abb87
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: jingham, emaste, lldb-commits, clayborg, ovyalov
Subscribers: emaste
Differential Revision: http://reviews.llvm.org/D16720
llvm-svn: 259344
Instead of opening the file in unicode mode, we need only encode
data which potentially has non-ASCII characters as UTF8 before
writing. This should work across both Python versions, and is
also far simpler than anything else discussed.
llvm-svn: 258969
* basestring is not a thing anymore. Must use `six.string_types`.
* Must use from __future__ import print_function in every new test
file.
llvm-svn: 258967
Previously the logic of skipIf and expectedFailure were 99%
the same, but they took different sets of arguments since they
were maintained separately, and had slightly differences in
their behavior. This makes everything consistent, there is now
only one real implementation, and the previous ones are changed
to use the single master implementation.
llvm-svn: 258966
Since pexpect doesn't exist on Windows, tests which are xfail'ed
are not being run at all because they are failing when the file
is imported due to the `import pexpect`. This puts the import
behind a conditional and makes an empty base class in the case
where pexpect is not present.
llvm-svn: 258965
SUMMARY:
Get the load address for the address given by symbol and function.
Earlier, this was done for function only, this patch does it for symbol too.
This patch also adds TestAvoidBreakpointInDelaySlot.py to test this change.
Reviewers: clayborg
Subscribers: labath, zturner, mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential Revision: http://reviews.llvm.org/D16049
llvm-svn: 258919
This is another example of a test that was looking for the thread
at index 0 instead of requesting the thread that was stopped at
the created breakpoint. This assumption isn't true on Windows 10.
llvm-svn: 258764
lldbinline tests previously did not run correctly unless there was already a
Makefile for them. This was because the syntax of the emitted Makefile made the
default make rule be the "cleanup" rule, which is pretty unhelpful. Now the
default rule is the one included from Makefile.rules, which is much better.
llvm-svn: 258763
Previously we were writing in the default encoding, which depends
on the operating system and is not guaranteed to be unicode aware.
On Python 3, this would lead to a situation where writing unicode
text to the log file generates an exception. The fix here is to
write session logs using the proper encoding, which incidentally
fixes another test, so xfail is removed from that.
llvm-svn: 258759
In Python 3, whitespace inconsistences are errors. This synthetic
provider had mixed tabs and spaces, as well as inconsistent
indentation widths. This led to the file not being imported,
and naturally the test failing. No functional change here, just
whitespace.
llvm-svn: 258751
SBProcess::ReadMemory and other related functions such as
WriteMemory are returning Python string() objects. This means
that in Python 3 that are returning Unicode objects. In reality
they should be returning bytes objects which is the same as a string
in Python 2, but different in Python 3. This patch updates the
generated SWIG code to return Python bytes objects for all
memory related functions.
One quirk of this patch is that the C++ signature of ReadCStringFromMemory
has it writing c-string data into a void*. This confuses our swig
typemaps which expect that a void* means byte data. So I hacked up
a custom typemap which maps this specific function to treat the
void* as string data instead of byte data.
llvm-svn: 258743
Python 3.5 is picky about writing strings to binary files, so we now open the
file in text mode, and we explicitly set the newline mode to avoid re-writing
it with CR+LF on Windows (which causes git to think the file had changed).
llvm-svn: 258704
Patch by Nitesh Jain.
Summary: The thread_start function in libc doesn't contain any epilogue and prologue instructions. Hence unwinding fail when we are stopped in thread_start.
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits, mohit.bhakkad, sagar, bhushan, jaydeep
Differential: reviews.llvm.org/D16136
llvm-svn: 258685
Patch by Nitesh Jain.
Summary: When incorrect type used for 'char' then (at least) one of the expression evaluates to incorrect value. Please refer to bug llvm.org/pr23069
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits, mohit.bhakkad, sagar, bhushan, jaydeep
Differential: reviews.llvm.org/D16132
llvm-svn: 258684
This is hitting an assert in clang when evaluating the
module load. I am seeing it locally on Xcode 7.3 public Beta 1
and on the llvm.org Green Dragon buildbot supposedly running
Xcode 7.0.
Tracked by:
https://llvm.org/bugs/show_bug.cgi?id=26267
llvm-svn: 258602
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
gcc by default does not accept for loop declarations in C files (one must choose C99 mode first,
which we don't). Place the declaration outside the loop, to make this code more conformant.
llvm-svn: 257166
On locked down systems (such as our buildbot) one needs to do a special dance to allow attaching
to processes. This commit adds this code to the TestBatchMode inferior.
llvm-svn: 257165
New test introduced in r257120 was failing on linux. The reason for that the regex for setting
the breakpoint was being applied to the "default file", which in this case was the asm file
containing the definition of the sleep() syscall (because after attach, we are stopped in the
sleep function). I have changed this use the more customary way of setting the breakpoint and
specifying the source file name explicitly.
llvm-svn: 257160
Batch mode is supposed to stop execution and return control to the user when an
exceptional stop occurs (crash, signal or instrumentation). But attach always stops
with a SIGSTOP on OSX (maybe on Linux too?) which would short circuit the rest of the
commands given.
This change allows a command result object to indicate that it expected to leave the
process stopped with an exceptional stop reason, and it is okay for batch mode to keep going.
<rdar://problem/22243143>
llvm-svn: 257120
The lldbinline inline-test mechanism will create a Makefile
if one does not exist in the test directory. This Makefile
and its *.d files were not getting cleaned up after a test run,
leaving trash in the source tree.
llvm-svn: 256961
The logic for skipping over the stop-and-restart events was incorrect as it was also skipping the
expectations. Implement it properly. No test is affected by this as they were not encountering
these events, but I encountered this issue when trying to use this function in a new test.
llvm-svn: 256928
This patch adds support the command 'source info' as follows:
(lldb) help source info
Display source line information (as specified) based on the current executable's
debug info.
Syntax: source info <cmd-options>
Command Options Usage:
source info [-c <count>] [-s <shlib-name>] [-f <filename>] [-l <linenum>] [-e <linenum>]
source info [-c <count>] [-s <shlib-name>] [-n <symbol>]
source info [-c <count>] [-a <address-expression>]
-a <address-expression> ( --address <address-expression> )
Lookup the address and display the source information for the corresponding
file and line.
-c <count> ( --count <count> )
The number of line entries to display.
-e <linenum> ( --end-line <linenum> )
The line number at which to stop displaying lines.
-f <filename> ( --file <filename> )
The file from which to display source.
-l <linenum> ( --line <linenum> )
The line number at which to start the displaying lines.
-n <symbol> ( --name <symbol> )
The name of a function whose source to display.
-s <shlib-name> ( --shlib <shlib-name> )
Look up the source in the given module or shared library (can be specified
more than once).
For example:
(lldb) source info --file x.h
Lines for file x.h in compilation unit x.cpp in `x
[0x0000000100000d00-0x0000000100000d10): /Users/dawn/tmp/./x.h:10
[0x0000000100000d10-0x0000000100000d1b): /Users/dawn/tmp/./x.h:10
The new options are used to fix the MI command:
-symbol-list-lines <file>
which didn't work for header files because it called:
target modules dump line-table <file>
which only dumps line tables for a compilation unit.
The patch also fixes a bug in the error reporting when no files were supplied to the command. Previously you'd get:
(lldb) target modules dump line-table
error:
Syntax:
error: no source filenames matched any command arguments
Now you get:
error: file option must be specified.
Reviewed by: clayborg, jingham, ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15593
llvm-svn: 256863
I'm getting rid of the expected timeouts. I'll XFAIL/skip any tests that show up as failing after
this (I haven't seen any when running locally, but maybe the buildbot will disagree).
llvm-svn: 256827
Summary:
This removes the old logic for rerunning flaky tests. The new test runners will take care of
rerunning failing tests.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15855
llvm-svn: 256824
I think it was timing out because of the attach deadlocks, which are now fixed. In any case, it
has passed last 200 buildbot runs, so I am enabling it.
llvm-svn: 256748
I believe the cause for this was the attach lockup fixed in r246756. I will enable this tests and
observe the buildbots for signs of problems.
llvm-svn: 256744
This is generating a SIGSEGV somewhere around 1 in 10 runs on OS X.
Skip the whole test to avoid testbot noise until we can get the
SIGSEGV addressed.
Tracking with:
https://llvm.org/bugs/show_bug.cgi?id=25924
llvm-svn: 256257
Summary: Also xfailed for GCC as there is an problem with debug info generation.
Reviewers: granata.enrico
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15657
llvm-svn: 256067
This patch adds support for printing global static const variables which are given a DW_AT_const_value DWARF tag by clang.
Fix for bug https://llvm.org/bugs/show_bug.cgi?id=25653
Reviewers: clayborg, tberghammer
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D15576
llvm-svn: 255887
We've now seen the rerun test phase hang in a few
scenarios. Eliminate the serial test runner (which
is not exercised nearly as much as the others), by
using a multi-worker test runner strategy with a single
worker. This should rule out whether this is related
to the serial test runner strategy.
llvm-svn: 255880
Summary:
This adds ability to mark test that do not complete due to hangs, crashes, etc., as "expected",
to avoid flagging the build red for a known problem. Functionally, this extends the scope of the
existing expectedFailureXXX decorators to cover these states as well. Once this is in, I will
start replacing the magic list of failing tests in dosep.py with our regular annotations which
should hopefully make code simpler.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15530
llvm-svn: 255763
This is meant to reduce the typing that one needs to do to get from the test subdirectory to actual test cases. Now one can just do
$ ./dotest.py ./testcases/<yaddayaddayadda>
llvm-svn: 255741
Summary:
DWARF 5 proposes a reinvented .debug_macro section. This change follows
that spec.
Currently, only GCC produces the .debug_macro section and hence
the added test is annottated with expectedFailureClang.
Reviewers: spyffe, clayborg, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15437
llvm-svn: 255729
Both of these markers are used in the test suit for annotating when a
test needs multi threaded support. Previously they had slightly
different meening but they converged to the point where they are used
interchangably. This CL removes the ENABLE_STD_THREADS one to simplify
the test suite and avoid some confusion.
Differential revision: http://reviews.llvm.org/D15498
llvm-svn: 255641
This is the listener's spawned connection, not the listener itself.
(i.e. this is the test runner's receiving side of test event sockets).
A standard socket.error will just issue an INFO statement and continue.
Something other than a socket.error will get an ERROR: printed (and
also continue).
Hopefully this gets us more info and also handles the completely
to-be-expected scenario that the test inferior might go down at
any point.
llvm-svn: 255581
Use of --rerun-all-issues will enable any test method failure, not just
test methods marked with the flakey decorator, to rerun.
Currently this does not change the flakey logic's immediate rerun
attempt. I want to make sure this doesn't cause any significant issues
before changing that part.
The rerun reporting is only known to work properly with the
default (new) BasicResultsFormatter reporting. Once we work out
any issues, I'll go back and make sure the curses output handles
it properly as well.
llvm-svn: 255543
Summary:
Previously the add_test_categories would simply overwrite the current set of categories for a
method. This change makes the decorator truly "add" categories, by extending the current set of
categories instead of replacing it.
To do this, I have:
- replaced the getCategories() property on a method (which was itself a method), with a simple
list property "categories". This makes add_test_categories easier to implement, and test
categories isn't something which should change between calls anyway.
- rewritten the getCategoriesForTest function to merge method categories with the categories of
the test case. Previously, it would just use the method categories if they were present. I have
also greatly simplified this method. Originally, it would use a lot of introspection to enable
it being called on various types of objects. Based on my tests, it was only ever being called
on a test case. The new function uses much less introspection then the preivous one, so we
should easily catch any stray uses, if there are any, as they will generate exceptions now.
Reviewers: zturner, tfiala, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15451
llvm-svn: 255493
When multiple functions are found by name, lldb removes duplicate entries of
functions with the same type, so the first function in the symbol context list
is chosen, even if it isn't in scope. This patch uses the declaration context
of the execution context to select the function which is in scope.
This fixes cases like the following:
int func();
namespace ns {
int func();
void here() {
// Run to BP here and eval 'p func()';
// lldb used to find ::func(), now finds ns::func().
}
}
Reviewed by: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15312
llvm-svn: 255439
Also adds full path info for exceptional exits and timeouts when
no test method is currently running.
Adds --rerun-all-issues command line arg. If specified, all
test issues are eligible for rerun. If not specified, only tests
marked flakey are eligible for rerun.
The actual rerunning will occur in an upcoming change. This
change just handles tha accounting of what should be rerun.
llvm-svn: 255438
This will be used in a future change to support rerunning flakey tests
that hit a test result isue in a low-load, single worker test runner phase.
This is implemented as an additive-style event rather than being
evaluated and added to the start_test event because the decorator code
only runs after the start_test event is created and sent. i.e.
LLDBTestResult.startTest() runs before the test method decorators run.
llvm-svn: 255351
LLDB don't detect the loading of a shared object file linked against the
main executable before the static initializers are executed for the
given module. Because of this it is not possible to get breakpoint hits
in these static initializers and to display proper debug info in case of
a crash in these codes.
llvm-svn: 255342
The new test summary formatter does not honor the "expected timeout" markings, which makes our
buildbots all red. I'm switching it off by default until we figure out a way to make this work.
llvm-svn: 255335
Summary: NetBSD is like FreeBSD and Linux in these routines.
Reviewers: clay.chang, tfiala, emaste, joerg
Subscribers: lldb-commits, emaste
Differential Revision: http://reviews.llvm.org/D15374
llvm-svn: 255308
Also adds enable.py/disable.py script to simplify turning on and off
the issue_verification tests helpful for testing a results formatter.
llvm-svn: 255161
This was an option to display a graphical progress bar. Nobody
is using this, and it doesn't work correctly anyway with the new
result formatter.
llvm-svn: 255153
This removes the failfast command line option as part of an effort
to simplify dotest and remove unused command line options. You can
still Ctrl+C any time you want to exit early.
llvm-svn: 255150
The main dotest.py should exit with a system return code of 1 on any
issue. This change fixes a place where I omitted counting the
exceptional exit value to determine if we should return 1 when using the
new summary results.
This change also puts a banner around the Issue Details section that comes
before the Test Result Summary.
llvm-svn: 255138
This change is a trial balloon to verify that the default test summary
output sends the right output for the buildbot issue detection script.
The effect of this change will be reverted after verifying the testbot
behavior. This change will not stay in as is and will knowingly create
noise, see this thread:
http://lists.llvm.org/pipermail/lldb-dev/2015-December/009048.html
llvm-svn: 255131
The results formatter system is now fed timeouts and exceptional process
exits (i.e. inferior dotest.py process that exited by signal on POSIX
systems).
If a timeout or exceptional exit happens while a test method is running
on the worker queue, the timeout or exceptional exit is charged and
reported against that test method. Otherwise, if no test method was
running at the time of the timeout or exceptional exit, only the test
filename will be reported as the TIMEOUT or ERROR.
Implements:
https://llvm.org/bugs/show_bug.cgi?id=24830https://llvm.org/bugs/show_bug.cgi?id=25703
In support of:
https://llvm.org/bugs/show_bug.cgi?id=25450
llvm-svn: 255097
This seems to be a legacy relic from days gone by where the
remote test suite runner operated completely differently than it
does today. git blames and comments traced this functionality
back to about 2012, and nobody seems to know anything about it
now.
llvm-svn: 255060
This removes the option to exclude a single directory. This is
part of an effort to remove unused options and cleanup the interface
to the test suite.
llvm-svn: 255048
The standard remote debugging workflow with gdb is to start the
application on the remote host under gdbserver (e.g.: gdbserver :5039
a.out) and then connect to it with gdb.
The same workflow is supported by debugserver/lldb-gdbserver with a very
similar syntax but to access all features of lldb we need to be
connected also to an lldb-platform instance running on the target.
Before this change this had to be done manually with starting a separate
lldb-platform on the target machine and then connecting to it with lldb
before connecting to the process.
This change modifies the behavior of "platform connect" with
automatically connecting to the process instance if it was started by
the remote platform. With this command replacing gdbserver in a gdb
based worflow is usually as simple as replacing the command to execute
gdbserver with executing lldb-platform.
Differential revision: http://reviews.llvm.org/D14952
llvm-svn: 255016
This change introduce 3 different working mode for Platform::LoadImage
depending on the file specs specified.
* If only a remote file is specified then the remote file is loaded on
the target (same behavior as before)
* If only a local file is specified then the local file is installed to
the current working directory and then loaded from there.
* If both local and remote file is specified then the local file is
installed to the specified location and then loaded from there.
The same options are exposed on the SB API with a new method LoadImage
method while the old signature presers its meaning.
On the command line the installation of the shared library can be specified
with the "--install" option of "process load".
Differential revision: http://reviews.llvm.org/D15152
llvm-svn: 255014
This moves all the global variables into a separate module called
`configuration`. This has a number of advantages:
1. Configuration data is centrally maintained so it's easy to get
a high level overview of what configuration data the test suite
makes use of.
2. The method of sharing configuration data among different parts
of the test suite becomes standardized. Previously we would
put some things into the `lldb` module, some things into the
`lldbtest_config` module, and some things would not get shared.
Now everything is shared through one module and is available to
the entire test suite.
3. It opens the door to moving some of the initialization code into
the `configuration` module, simplifying the implementation of
`dotest.py`.
There are a few stragglers that didn't get converted over to using
the `configuration` module in this patch, because it would have grown
the size of the patch unnecessarily. This includes everything
currently in the `lldbtest_config` module, as well as the
`lldb.remote_platform` variable. We can address these in the future.
llvm-svn: 254982
It was previously reverted due to issues that showed up only on linux. I was able to reproduce these issues and fix the underlying cause.
So this is the same patch as 254476 with the following two fixes:
- Fix not trying to complete classes that don't have external sources
- Fix ClangASTSource::CompleteType() to check the decl context of types that it finds by basename to ensure we don't complete a type "S" with a type like "std::S". Before this fix ClangASTSource::CompleteType() would accept _any_ type that had a matching basename and copy it into the other type.
<rdar://problem/22992457>
llvm-svn: 254980
This cleans up dotest.py and is a pre-step for getting
the test inferior runner to send post-inferior run events
to the events collector, as this code needs to be accessed
from within dosep.py.
llvm-svn: 254979
Summary:
The base make(1) on NetBSD is BSD make.
In the default installation of NetBSD GNU make comes via pkgsrc under the gmake name.
Reviewers: emaste, tfiala, clayborg
Subscribers: joerg, lldb-commits
Differential Revision: http://reviews.llvm.org/D15261
llvm-svn: 254947
There is already a class called LLDBTestResults which I would like
to move into a separate file, but the most appropriate filename
was taken.
llvm-svn: 254946
Summary:
The getwd() and getcwd() functions conform to IEEE Std 1003.1-1990
(POSIX.1). The IEEE Std 1003.1-2004 (POSIX.1) revision marked
getwd() as legacy and recommended the use of getcwd() instead. The IEEE
Std 1003.1-2008 (``POSIX.1'') revision removed getwd() from the
specification.
The ability to specify a NULL pointer and have getcwd() allocate memory
as necessary is an extension.
The getwd() function appeared in 4.0BSD.
Reviewers: emaste, tfiala, clayborg
Subscribers: lldb-commits, joerg
Differential Revision: http://reviews.llvm.org/D15260
llvm-svn: 254944
Allow both '-var-list-children var0' and '-var-list-children "var0"' to be used with the -var-list-children command. GDB MI allows for this and it is necessary if the variable name contains spaces, such as var5.std::_Vector_base<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<cahr> > > >.
Differential Revision: http://reviews.llvm.org/D15168
llvm-svn: 254941
This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the
original commit, where we would incorrectly interrupt the process if the interrupt request came
just as we were about to send the stopped event to the public.
llvm-svn: 254902
Summary:
Because of the large number of XFAILs TestThreadStates has decayed quite a bit. This commit does
the following:
- removes the "breakpoint list" expectations. Most tests have been failing on this, because the
command output changed quite a while back. I remove it, because run_break_set_by_file_and_line
already does a decent amount of checking
- fixup test_state_after_expression: this was calling the wrong function by mistake. As now the
function actually tests something (which we know is broken), I needed to XFAIL it as well.
- replaces the sleep() with a proper wait-for-event functionality in parts which use async mode,
to stabilize the one function that actually tests something.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15233
llvm-svn: 254901
Test summary counts now show at the end, with issue details
above.
Issue details now print "ISSUE_TYPE: test method (relative path)".
Relative paths are relative to the
packages/Python/lldbsuite/test directory.
Sample output:
test/dotest.py --executable `pwd`/build/Debug/lldb --results-formatter lldbsuite.test.basic_results_formatter.BasicResultsFormatter --threads 12
Testing: 415 test suites, 12 threads
415 out of 415 test suites processed - TestLldbGdbServer.py
Test Results
Total Test Methods Run (excluding reruns): 2470
Test Method rerun count: 0
Details:
UNEXPECTED SUCCESS: test_symbol_name_dsym (functionalities/completion/TestCompletion.py)
UNEXPECTED SUCCESS: test_symbol_name_dwarf (functionalities/completion/TestCompletion.py)
===================
Test Result Summary
===================
Success: 1329
Expected Failure: 79
Failure: 0
Error: 0
Unexpected Success: 2
Skip: 1060
llvm-svn: 254890
Summary: This is used in tests.
Reviewers: emaste, tfiala, clayborg
Subscribers: zturner, lldb-commits, joerg
Differential Revision: http://reviews.llvm.org/D15065
llvm-svn: 254853
Patch by Nitesh Jain.
Summary: There is no debug information generated for variable index with –O3 optimization flag. The DW_AT_location tag in DWARF debug_info section is empty.
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits, mohit.bhakkad, sagar, bhushan, jaydeep
Differential: http://reviews.llvm.org/D15224
llvm-svn: 254850
This test would fail before if conditional breakpoints weren't
working correctly, and the nature of the test (spinning up 10
threads, etc) opens the door to raciness.
This patch vastly simplifies the test, removes the need for relying
on conditional expression evaluation, and as a result makes the
correctness of the test vastly easier to reason about and reduces
flakiness.
Differential Revision: http://reviews.llvm.org/D15241
Reviewed By: Jim Ingham
llvm-svn: 254792
SUMMARY:
Marked TestCrashDuringStep.py as XFAIL for MIPS. The test generates IO error due to breakpoint at invalid address.
Reviewers: clayborg, labath
Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits
Differential Revision: http://reviews.llvm.org/D15182
llvm-svn: 254710
Previously we used sys.os.path for appending target pathes what failed
when cased dlopen to fail on the target because of the '\'.
The fix won't work for local Windows tests but dlopen don't available
on Windows anyway so the test don't make sense in that context.
llvm-svn: 254602
Also cleans up some usages of strings where symbolic names
were safer and made more sense.
Try a test run with something like this to check out the new
basic results formatter (not used by default):
time test/dotest.py --executable `pwd`/build/Debug/lldb --results-formatter lldbsuite.test.basic_results_formatter.BasicResultsFormatter --results-file stdout
This will yield something like:
Testing: 1 test suites, 8 threads
1 out of 1 test suites processed - TestHelp.py
Test Results
Total Test Methods Run (excluding reruns): 13
Test Method rerun count: 0
===================
Test Result Summary
===================
Success: 13
Expected Failure: 0
Failure: 0
Error: 0
Unexpected Success: 0
Skip: 0
Whereas something with a bit of error will look more like this:
42 out of 42 test suites processed - TestSymbolTable.py
Test Results
Total Test Methods Run (excluding reruns): 166
Test Method rerun count: 0
===================
Test Result Summary
===================
Success: 93
Expected Failure: 10
Failure: 2
Error: 2
Unexpected Success: 0
Skip: 59
Details:
FAIL:
TestModulesInlineFunctions.ModulesInlineFunctionsTestCase.test_expr_dsym
(/Users/tfiala/work/lldb-tot/git-svn/lldb/packages/Python/lldbsuite/test/lang/objc/modules-inline-functions/TestModulesInlineFunctions.py)
FAIL:
TestModulesInlineFunctions.ModulesInlineFunctionsTestCase.test_expr_dwarf
(/Users/tfiala/work/lldb-tot/git-svn/lldb/packages/Python/lldbsuite/test/lang/objc/modules-inline-functions/TestModulesInlineFunctions.py)
ERROR: TestObjCCheckers.ObjCCheckerTestCase.test_objc_checker_dsym
(/Users/tfiala/work/lldb-tot/git-svn/lldb/packages/Python/lldbsuite/test/lang/objc/objc-checker/TestObjCCheckers.py)
ERROR: TestObjCCheckers.ObjCCheckerTestCase.test_objc_checker_dwarf
(/Users/tfiala/work/lldb-tot/git-svn/lldb/packages/Python/lldbsuite/test/lang/objc/objc-checker/TestObjCCheckers.py)
The Details header only prints if there are any issues to report. The
Details section has tags that should get picked up using the normal
issue text scrapers (e.g. buildbot).
Test numbers reported are strictly test method runs.
The rerun bit at the top is in support of the multi-pass test
runner code (to run the low-load, single worker test pass for
tests that failed the first run), which I'll be able to put up
for review after this.
ResultsFormatters now have the ability to indicate they replace
the legacy summary, as this one does.
Once we come to agreement on the exact format, I will switch
us over to using this by default.
llvm-svn: 254530
On android the symbols exposed by libdl (dlopen, dlclose, dlerror)
prefixed by "__dl_". This change moves the handling of process
load/unload to the platform object and override it for android to
handle the special prefix.
Differential revision: http://reviews.llvm.org/D11465
llvm-svn: 254504
Summary:
- Problem occurs when:
-- 32-bit inferiors run on x86_32 machine and
the architecture doesn't have AVX feature
-- This causes FPRType to be set to eFPRTypeFXSAVE
-- PTRACE_GETFPREGS was being used to read FXSAVE area
-- For 32-bit inferiors running on x86_32 machine,
PTRACE_GETFPREGS reads FSAVE area and not FXSAVE area
- Changed ptrace API to PTRACE_GETREGSET for 32-bit inferiors
-- This reads FPR data in FXSAVE format.
-- For 64-bit inferiors, no change has been made.
- Modified XFAIL for TestReturnValue.py
-- Earlier, this test was passing for Linux OS
-- Now, it passes for Android OS as well
Change-Id: Ieed72bc969b79516fc7b263b32493aa1e7a1a2ac
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: ovyalov, jingham, lldb-commits, tberghammer, labath
Subscribers: jevinskie, labath, tberghammer, danalbert
Differential Revision: http://reviews.llvm.org/D15042
llvm-svn: 254499
This is done by finding the types that are forward declarations that come from a module, and loading that module's debug info in a separate lldb_private::Module, and copying the type over into the current module using a ClangASTImporter object. ClangASTImporter objects are already used to copy types from on clang::ASTContext to another for expressions so the type copying code has been around for a while.
A new FindTypes variant was added to SymbolVendor and SymbolFile:
size_t
SymbolVendor::FindTypes (const std::vector<CompilerContext> &context, bool append, TypeMap& types);
size_t
SymbolVendor::FindTypes (const std::vector<CompilerContext> &context, bool append, TypeMap& types);
The CompilerContext is a way to represent the exact context of a type and pass it through an agnostic API boundary so that we can find that exact context elsewhere in another file. This was required here because we can have a module that has submodules, both of which have a "foo" type.
I am not able to add tests for this yet as we currently don't build our C/C++/ObjC binaries with the clang binary that we build. There are some driver issues where it can't find the header files for the C and C++ standard library which makes compiling these tests hard. We can't also guarantee that if we are building with clang that it supporst the exact format of -gmodule debugging that we are trying to test. We have had other versions of clang that had a different implementation of -gmodule debugging that we are no longer supporting, so we can't enable tests if we are building with clang without compiling something and looking at the structure of the DWARF that was generated to ensure that it is the format we can actually use.
llvm-svn: 254476
Summary:
The following situation was occuring in TestAttachResume:
- we did a "continue" from a breakpoint (which involves a private start-stop to step over the
breakpoint)
- after receiving the stop-reply from the step-over, we issue a "detach" (which requires a
process interrupt)
- at this moment, the public state is "running", private state is "about-to-be-stopped" (the
stopped event was broadcast, but it was not received yet)
- StopForDestroyOrDetach (public thread) notes the public state is running, sends an interrupt
request to the private thread
- private thread gets the eBroadcastBitInterrupt (before the eStateStopped message), and asks the
process plugin to stop (via Halt())
- process plugin says it has nothing to do as the process is already stopped
- private thread shrugs and carries on. receives the stop event, restores the breakpoint and
resumes the process.
- after a while, the public thread times out and says it failed to stop the process
This patch does the following:
- splits Halt() into two functions, private and public, their usage depends on the context
- public Halt(): sends eBroadcastBitInterrupt to the private thread and waits for the Stop
event
- HaltPrivate(): asks the plugin to stop and makes a note that the halt was requested. When the
next stop event comes it sets the interrupt flag on it.
- removes HijackPrivateProcessEvents(), as the only user (old Halt()) has gone away
- removes the m_currently_handling_event hack, as the new Halt() does not need it
- adds a use_run_lock parameter to public Halt() and WaitForProcessToStop(). This was needed
because RunThreadPlan uses Halt() while holding the run lock and we don't want Halt() to take
it away from him.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14989
llvm-svn: 254403
SUMMARY:
For MIPS, ARCH is specified without m.
Reviewers: clayborg
Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits
Differential Revision: http://reviews.llvm.org/D14978
llvm-svn: 254376
These tests were fixed by r253026 but they was failing on the linux
build bot because of a system setup problem. Remove xfail from them
after we fixed the build bot.
llvm-svn: 254163
This test was already expectedFlakeyLinux for occasional failures on the
Linux buildbot. It seems the new FreeBSD buildbot fails the same way on
occasion.
llvm.org/pr25172
llvm-svn: 254002
This passes on my FreeBSD stable/10 desktop and my new FreeBSD
11-current buildbot (which is not yet hooked up to the buildmaster).
llvm.org/pr18190
llvm-svn: 254000
Summary:
This reverts commit 251965377bdfb6227eea42c12a792c059e4e8a4b
as a test marked "skipIf(compiler='gcc')" runs when testing with GCC.
Reviewers: amccarth
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14852
llvm-svn: 253631
-fms-compatibility-version defaults to VS 2013. When using
VS 2015, this will lead to compilation failures of the test
inferiors in the C++ standard library for language conformance
reasons.
The fix here is to simply pass -fms-compatibility-version=19.0 when
we detect that a VS 2015 compiler is present. Even though we're
actually using clang to do the compilation, clang uses this same
detection algorithm to determine the location of the standard
library. So this check is tantanmount to saying "If clang is going
to find MSVC 2015's standard library, then pass 19.0 for
-fms-compatibility-version.
llvm-svn: 253589
