| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
of kalimba architecture variants.
llvm-svn: 218749
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change does the following:
* Remove test/c++/...
* Add gtest.
* Add gtest/unittest directory for unittesting individual classes.
* Add an initial Plugins/Process?linux/ThreadStateCoordinatorTest.cpp.
- currently failing a test (intentional).
- added a bare-bones ThreadStateCoordinator.cpp to Plugins/Process/Linux,
more soon. Just enough to prove out running gtest on Ubuntu and MacOSX.
* Added recursive make machinery so that doing a 'make' in gtest/ is
sufficient to kick off the existing test several directories down.
- Caveat - I currently short circuit from gtest/unittest/Makefile directly to
the one and only gtest/unittest/Plugins/Process/Linux directory. We'll need
to add the intervening layers. I haven't done this yet since to fix the
Xcode test failure correspondence, I may need to add a python layer which
might just handle the directory crawling.
* Added an Xcode project to the lldb workspace for gtest.
- Runs the recursive make system in gtest/Makefile.
- Default target is 'test'. test and clean are supported.
- Currently does not support test failure file/line correspondence.
Requires a bit of text transformation to hook that up.
llvm-svn: 218460
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Makes use of LLVM gtest support. This does *not* run as part of
the lldb test suite.
I'm using it to start testing some components that
I'll be adding to the inner guts of NativeThreadLinux to more
maintainably handle thread states and deferred thread state notification.
Runs with default Makefile target "test" using gmake within a given
test directory (currently only test/c++/native_process/thread_state_coordinator).
The Makefile.rules currently assume it is using the LLVM gtest. It works on
a canonical MacOSX dir structture (i.e. lldb, lldb/llvm, lldb/llvm/tools/clang).
It also works on Ubuntu assuming the standard dir layout of llvm, llvm/tools/clang,
llvm/tools/lldb. In this case, it expects a directory called build-debug parallel
to the llvm source dir. All directory assumptions can be overridden with
environment variables. See test/c++/make/Makefile.rules for details.
We'll want to make this smarter in the future, particularly around finding the LLVM build
output dir.
llvm-svn: 218422
|
|
|
|
|
|
|
|
| |
don't get freed too early
Reviewed at http://reviews.llvm.org/D5452
llvm-svn: 218323
|
|
|
|
|
|
|
|
|
|
| |
The test used to trigger an assertion failure "Cannot get layout of
forward declarations!", but it no longer fails when built with
Clang 3.4.1 (system compiler) or 3.5 from SVN on FreeBSD.
llvm.org/pr17231
llvm-svn: 218196
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
if a "file a.out" auto selected a different platform than the selected one.
Changes include:
- fix it so you can select the "host" platform using "platform select host"
- change all callbacks that create platforms to returns shared pointers
- fix TestImageListMultiArchitecture.py to restore the "host" platform by running "platform select host"
- Add a new "PlatformSP Platform::Find(const ConstString &name)" method to get a cached platform
- cache platforms that are created and re-use them instead of always creating a new one
llvm-svn: 218145
|
|
|
|
|
|
|
|
|
| |
well as C++
For the Objective-C case, we do not have a "function type" notion, so we actually end up wrapping the clang ObjCMethodDecl in the Impl object, and ask function-y questions of it
In general, you can always ask for return type, number of arguments, and type of each argument using the TypeMemberFunction layer - but in the C++ case, you can also acquire a Type object for the function itself, which instead you can't do in the Objective-C case
llvm-svn: 218132
|
|
|
|
|
|
| |
more reliable when it comes to stopping on a specific line.
llvm-svn: 218079
|
|
|
|
|
|
| |
case is a fairly bullet-proof recipe for disaster. Use the * enabling feature to workaround this. Fixes rdar://18358649
llvm-svn: 217927
|
|
|
|
|
|
| |
member function in more detail. A type was really quite vague. This now has function name, kind, as well as function type
llvm-svn: 217828
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
define a one-liner short help for their command
Also, in case they don't define any, change the default from "Run Python function <blah>" into "For more information run help <blah>"
The core issue here is that Python only allows one docstring per function, so we can't really attach both a short and a long help to the same command easily
There are alternatives but this is not a pressing enough concern to go through the motions quite yet
Fixes rdar://18322737
llvm-svn: 217795
|
|
|
|
|
|
|
|
| |
* Fixes the local stack variable return pointer usage in NativeThreadLinux::GetName().
* Changes NativeThreadProtocol::GetName() to return a std::string.
* Adds a unit test to verify thread names don't regress in the future. Currently only run on Linux since I know default thread names there.
llvm-svn: 217717
|
|
|
|
|
|
| |
classes. Add plumbing for that all the way up to the SB layer
llvm-svn: 217701
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Sends a SIGSTOP to the process.
* Fixes busted SIGSTOP handling. Now builds a list of non-stopped
that we wait for the PTRACE group-stop for. When the final must-stop
tid gets its group stop, we propagate the process state change.
Only the signal receiving the notification of the pending SIGSTOP
is marked with the SIGSTOP signal. All the rest, if they weren't
already stopped, are marked as stopped with signal 0.
* Fixes a few broken tests.
* Marks the Linux test I added earlier as expect-pass (no longer XFAIL).
Implements fix for http://llvm.org/bugs/show_bug.cgi?id=20908.
llvm-svn: 217647
|
|
|
|
|
|
|
|
|
|
| |
app is interrupted.
The Linux version is marked XFAIL for the moment, fixing next.
Related to http://llvm.org/bugs/show_bug.cgi?id=20908.
llvm-svn: 217613
|
|
|
|
|
|
|
|
|
|
|
| |
This change implements this ticket:
http://llvm.org/bugs/show_bug.cgi?id=20899
Adds the qThreadStopInfo RSP command for llgs and includes a test that
verifies both debugserver and llgs respond with something reasonable
on a multithreaded app.
llvm-svn: 217549
|
|
|
|
|
|
|
|
| |
test/functionalities/connect_remote/TestConnectRemote.py when port 12345 is already in use
Reviewed at http://reviews.llvm.org/D5221
llvm-svn: 217388
|
|
|
|
|
|
| |
during test run.
llvm-svn: 217387
|
|
|
|
|
|
|
|
|
| |
Reviewed at
http://reviews.llvm.org/D5219
and
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140901/012809.html
llvm-svn: 217300
|
|
|
|
|
|
| |
Reviewed at http://reviews.llvm.org/D4596
llvm-svn: 217116
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llgs Linux is no longer doing the translation to some gdb fixed signal
numbers. This change modifies the test method to take in the signo
expected for a segfault. The debugserver test uses the fixed gdb number,
and everything else uses signal.SIGSEGV for the platform.
Sidenote: I somehow did not see this reported in multicore tests.
I will need to verify that we aren't missing test failures in that
script. I need to verify why this wasn't more obvious with
test/dosep.py.
llvm-svn: 216770
|
|
|
|
|
|
|
|
| |
at a time.
<rdar://problem/13314462>
llvm-svn: 216747
|
|
|
|
|
|
|
| |
Patch by Sean Callanan.
<rdar://problem/18140875>
llvm-svn: 216504
|
|
|
|
|
|
| |
time it runs.. probably leftover from when I was debugging it
llvm-svn: 216502
|
|
|
|
|
|
|
|
|
|
|
|
| |
defining triple.
And likewise for qProcessInfo on Linux, but ensures cputype/cpusubtype is not defined. The
Apple case is the more important one, since we take a slightly different path to initialize
ProcessGDBRemote-related remote host/process info if triple is present.
Related to http://llvm.org/bugs/show_bug.cgi?id=20755.
llvm-svn: 216473
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change addresses this bug:
http://llvm.org/bugs/show_bug.cgi?id=20755
This change:
* Modifies llgs to send triple instead of cputype and cpusubtype when not on Apple platforms in qProcessInfo.
* Modifies lldb's GDBRemoteCommunicationClient to handle the triple returned from qProcessInfo if given.
When given, it will prefer to use triple over cputype and cpusubtype.
* Adds gdb-remote protocol tests to verify that cputype and cpusubtype are specified on darwin, and that triple is specified on Linux.
llvm-svn: 216470
|
|
|
|
|
|
|
|
|
| |
I'm about to add some more qProcessInfo tests so I wanted to first pull them out
of the monolithic TestLldbGdbServer test case class.
Related to http://llvm.org/bugs/show_bug.cgi?id=20755
llvm-svn: 216465
|
|
|
|
|
|
| |
lldb::SBFileSpec objects with the filename filled in for directory paths.
llvm-svn: 216399
|
|
|
|
| |
llvm-svn: 215565
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many of the test executables use pthreads directly. This isn't
portable on Windows, so this patch converts these test to use
C++11 threads and mutexes. Since Windows' implementation of
std::thread classes throw and catch from header files, this patch
also disables exceptions when compiling with clang on Windows.
Reviewed by: Todd Fiala, Ed Maste
Differential Revision: http://reviews.llvm.org/D4816
llvm-svn: 215562
|
|
|
|
|
|
|
|
|
| |
their ilk.
Added llgs/debugserver gdb-remote tests around SIGABRT and SIGSEGV signal reception
notification. Found a few bugs in exception signal handling in Linux llgs. Fixed those.
llvm-svn: 215458
|
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4826
Reviewed by: Enrico Granata
llvm-svn: 215256
|
|
|
|
|
|
| |
llvm.org/pr20548
llvm-svn: 214960
|
|
|
|
| |
llvm-svn: 214922
|
|
|
|
|
|
|
|
|
|
| |
The test produces lines that start with "<word>: " which confuses the
buildbot log parser. Disable the test until either the test is fixed
or the buildbot can deal with the undesired output.
llvm.org/pr20545
llvm-svn: 214900
|
|
|
|
| |
llvm-svn: 214575
|
|
|
|
|
|
| |
llvm.org/pr20476
llvm-svn: 214527
|
|
|
|
| |
llvm-svn: 214522
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, CMake was invoking the test runner and not specifying
what architecture to use when building test executables. The
Makefiles for the test executables then had logic to choose x64
by default. This doesn't work on Windows because the test compiler
would then try to link against the 64-bit MSVCRT and not find them
since only the 32-bit MSVCRT was in the path.
This patch addresses this by figuring out, at CMake time, whether
or not you are building LLDB with a 64 or 32-bit toolchain. Then,
it explicitly passes this value to the test runner, causing the
test runner to build tests whose architecture matches that of LLDB
itself. This can still be overridden by setting the CMake variable
LLDB_TEST_EXECUTABLE_ARCH=(x64|x86)
llvm-svn: 214443
|
|
|
|
| |
llvm-svn: 214441
|
|
|
|
|
|
| |
llvm.org/pr15037
llvm-svn: 214402
|
|
|
|
| |
llvm-svn: 214351
|
|
|
|
|
|
| |
Also adds a new test case for vAttach;{pid} for llgs and debugserver.
llvm-svn: 214236
|
|
|
|
| |
llvm-svn: 214207
|
|
|
|
|
|
|
|
|
|
|
| |
This was causing core dumps on MacOSX and was not properly
cleaning up the state of the inferior before exiting.
The test was overriding def tearDown(), but failed to
call the base class after doing its own cleanup. This
essentially eliminated normal clean-up activity.
llvm-svn: 214138
|
|
|
|
|
|
| |
Also includes --reverse-connect tests for llgs and debugserver.
llvm-svn: 214031
|
|
|
|
|
|
|
|
| |
(and fairly unimportant) bug.
Keep a test for that bug, but let the useful parts of the test run anyway.
llvm-svn: 213875
|
|
|
|
|
|
| |
architecture when trying to create a target, that it would fail, but not cause LLDB to crash.
llvm-svn: 213781
|
|
|
|
|
|
|
|
|
| |
Verify that ObjectFileELF's kalimba detection works regardless
of the host platform.
Change by Matthew Gardiner.
llvm-svn: 213763
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the test runner makes the assumption that it will run
commands through /bin/sh. This is obviously not true on Windows,
so this patch abstracts this logic out somewhat. Instead of
having the caller build the command string himself, the caller
will now pass in argument list of the form [[a, b], [c, d], ...]
which will get converted into a string of the form a b; c d or
a b && c d, depending on the platform.
Reviewed by: Todd Fiala
Differential Revision: http://reviews.llvm.org/D4590
llvm-svn: 213669
|