A freebsd issue with rm prevents '[g]make clean' from working if $(DSYM)
is empty (fts_open(3) fails if passed an empty argument).
To work around this, simplify the clean target by using three separate
rm invocations: one for the common files, one for the case of non-empty
$(DYLIB_NAME), and one for non-empty $(DSYM).
Issue diagnosed (and reported to FreeBSD) by John Wolfe.
llvm.org/pr17933
llvm-svn: 203253
It speeds up running the full test suite on my HP z620 Ubuntu machine with 32 hyperthreaded CPUs from 11 minutes to about 1m13s (about 9x).
The default behavior is to run single-threaded as before. If the environment variable LLDB_TEST_THREADS is set, a Python work queue is set up with that many worker threads.
To avoid collisions within a test directory where multiple tests make use of the same prebuilt executable, the unit of work for the worker threads is a single directory (that is, all tests within a directory are processed in the normal serial way by a single thread).
tfiala & I have run this way a number of times; the only issue I found was that the TestProcessAttach.py test failed once, when attempting to attach to the process "a.out" by name. I assume this is because some other thread was running an executable of that name at the same time, and we were attempting to attach to the wrong one, so I changed that test to use a different executable name (that change is also included in this commit).
llvm-svn: 203180
The following two tests showed up as XFAIL even though they should
always be skipped on Linux, due to the @unittest2.expectedFailure
annotation appearing above the @dsym_test annotation:
TestObjCNewSyntax.ObjCNewSyntaxTestCase.test_expr_with_dsym
TestBlocks.BlocksTestCase.test_expr_with_dsym.
For those two, I simply moved the @dsym_test annotation to the top so
that it would be marked for skip ahead of being marked for XFAIL.
TestObjCNewSyntax.ObjCNewSyntaxTestCase.test_expr_with_dwarf I marked
as @skipIfLinux since my understanding is that isn't a valid test to
run on Linux. So rather than categorize as a fail (i.e. something
wrong to be fixed), just skip it. (My recent changes to Linux tests
have been following that model: if it could never work, skip; if it's
broken, mark XFAIL so we can easily track, fix, notice the fix and
adjust accordingly).
TestDeadStrip.DeadStripTestCase.test_with_dwarf I had previously
marked as XFAIL but this would never work on Linux with the current
linker AFAICT. Marked it as skip.
llvm-svn: 202788
I suspect I may have misrun the test previously for check-in
r202456 re: pr15258. This test fails consistently on my end.
I changed the test to expected failure on Linux.
llvm-svn: 202517
This test passed 50 out of 50 times for me on Unbuntu 12.04 LTS x86_64
with lldb built using gcc 4.8.2 and July 2013 libedit.
This is related to:
http://llvm.org/bugs/show_bug.cgi?id=16170
llvm-svn: 202512
Related to this bug:
http://llvm.org/bugs/show_bug.cgi?id=16714
On TOT lldb svn r202507, I found several of the tests disabled within
TestConcurrentEvents.py to run fine, and several of them to fail 100%
of the time on my system (25 out of 25 times).
This changes the following tests for Linux:
Enables (these all work consistently):
* test_many_watchpoints_dwarf
* test_signal_watch_break_dwarf (line 250)
* test_signal_watch_break_dwarf (line 260 - same named test?)
* test_crash_with_watchpoint_dwarf
* test_crash_with_watchpoint_breakpoint_signal_dwarf
* test_delayed_crash_with_breakpoint_watchpoint_dwarf
Marks as expected failure (these all fail consistently):
* test_many_watchpoints_dwarf
* test_watch_break_dwarf
* test_delay_watch_break_dwarf
* test_watch_break_dwarf_delay
* test_signal_watch_dwarf
* test_delay_signal_watch_dwarf
* test_signal_delay_watch_dwarf
* test_two_breakpoints_one_watchpoint_dwarf
* test_breakpoints_delayed_breakpoint_one_watchpoint_dwarf
* test_two_watchpoint_threads_dwarf
* test_watchpoint_with_delay_watchpoint_threads_dwarf
* test_two_watchpoints_one_breakpoint_dwarf
* test_two_watchpoints_one_delay_breakpoint_dwarf
* test_watchpoint_delay_watchpoint_one_breakpoint_dwarf
* test_two_watchpoints_one_signal_dwarf
* test_signal_watch_break_dwarf
llvm-svn: 202511
Related to this bug:
http://llvm.org/bugs/show_bug.cgi?id=15037
Previously this was marked as skipped. I tried running it 10 times in
a row and it failed every time. Switched it to XFAIL.
llvm-svn: 202506
This is related to:
http://llvm.org/bugs/show_bug.cgi?id=15258
I ran this test 10 times successfully against Ubuntu 12.04 LTS x86_64
with lldb built with gcc 4.8.2 and July 2013 libedit.
llvm-svn: 202456
Implement x86_64 debug register read/write in support of hardware
watchpoints. Hoist LinuxThread::TraceNotify code back into
POSIXThread::TraceNotify()
Patch by John Wolfe.
We still need to rework this later to avoid the #ifdef FreeBSD.
llvm-reviews.chandlerc.com/D2572
llvm.org/pr16706
llvm-svn: 201706
Revert the spirit of r199857 - a convincing case can be made that overriding a summary's format markers behind its back is not the right thing to do
This commit reverts the behavior of the code to the previous model, and changes the test case to validate the opposite of what it was validating before
llvm-svn: 201455
Fixes http://llvm.org/bugs/show_bug.cgi?id=18656.
Note this exposes a failure on Linux of
TestInferiorAssert.test_inferior_asserting_disassemble, similar to how
it fails on FreeBSD. I'll file a bug for this next. We're now getting
another frame beyond where we used to prior to this fix, so the fix is
exposing failures in previosly not-reachable frames.
Much thanks to Jason Molenda, who had much to do with helping figure
out where unwinding was breaking.
llvm-svn: 200600
The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)
We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.
llvm-svn: 200263
ValueObjectPrinter could enter an infinite loop while trying to display an aptly formed ValueObject: a reference, with a child of some pointer type, such that the pointees chain ended up pointing back to some part of itself - a pointer to itself being the simplest such case
Fixed here by only setting a pointer depth when needed, and ensuring that we won't overflow and wrap the pointer depth when it's zero.
llvm-svn: 200247
The alias test "exprf x 1234" expands to "expr -f x 1234" and is
expected to fail: it ends up trying to evaluate the invalid expression
void
$__lldb_expr(void *$__lldb_arg)
{
-f x 1234;
}
On FreeBSD LLDB ends up finding a static function f() in a math library,
and thus the error produced does not include "use of undeclared
identifier 'f'".
We will report failure to parse the expression in any case, so require
only that error message.
llvm-svn: 199623
Part 1 changes PlatformLinux::CreateInstance to always create with
is_host=false; that method is only used as the plug-in creator method
associated with the remote-linux platform plugin, and should therefore
always be remote.
Part 1 patch by Steve Pucci.
Part 2: fix a test break on linux.
In test/functionalities/thread/thread_specific_break, when using gcc,
either C99 mode would need to be enabled, or the code would need to
change. I changed a couple loop variable definitions to conform
to pre-C99 to simplify testing the fix. The second issue was
the necessity to include -lpthread as a linker option in the Makefile.
Any issues with that part are due to me (Todd Fiala).
llvm-svn: 199426
control to the user anyway. This was put in to handle monitors that would say there was no
stop reason when you first attached to them. But it broke the case where you hit a thread specific
breakpoint on many threads, but NOT the one specified in the breakpoint. I work around this
by only doing the junky override when the StopID is 0 - i.e. on first attach.
This commit also adds a test for thread specific breakpoints.
llvm-svn: 199290
The "type format add" command gets a new flag --type (-t). If you pass -t <sometype>, upon fetching the value for an object of your type,
LLDB will display it as-if it was of enumeration type <sometype>
This is useful in cases of non-contiguous enums where there are empty gaps of unspecified values, and as such one cannot type their variables as the enum type,
but users would still like to see them as-if they were of the enum type (e.g. DWARF field types with their user-reserved ranges)
The SB API has also been improved to handle both types of formats, and a test case is added
llvm-svn: 198105
test_convenience_registers_16bit_with_process_attach fails due to
pr18200. The test has a @expectedFailureFreeBSD decorator, but it
appears this does not catch a RuntimError exception raised in the test
infrastructure, so the test still reports failure. For now just skip
it.
llvm-svn: 197174
Jim Ingham