With this change, both local-process llgs and remote-target llgs stdout/stderr
handling from inferior work correctly.
Several log lines have been added around PTY and stdout/stderr redirection
logic on the lldb client side.
Regarding remote llgs execution, see the following:
With these changes, remote llgs with $O now works properly:
$ lldb
(lldb) platform select remote-linux
(lldb) target create ~/some/inferior/exe
(lldb) gdb-remote {some-target}:{port}
(lldb) run
The sequence above will correctly redirect stdout/stderr over gdb-remote $O,
as is needed for remote debugging. That sequence assumes there is a lldb-gdbserver
exe running on the target with {some-host}:{port}.
You can replace the gdb-remote command with a '(lldb) platform connect
connect://{target-ip}:{target-port}'. If you do this and have a
lldb-platform running on the remote end, it will go ahead and launch
llgs for lldb for each target instance that is run/attached.
For local debugging with llgs, the following sequence also works, and
uses local PTYs instead to avoid $O and extra gdb-remote messages:
$ lldb
(lldb) settings set platform.plugin.linux.use-llgs true
(lldb) target create ~/some/inferior/exe
(lldb) run
The above will run the inferior using llgs on the local host, and
will use PTYs rather than $O redirection.
This change also removes the logging that happened after the fork but
before the exec when llgs is launching a new inferior process. Some
aspect of the file handling during that portion of code would not do
the right thing with log handling. We might want to go back later
and have that communicate over a pipe from the child to parent to pass
along any messages that previously were logged in that section of code.
llvm-svn: 219578
See http://reviews.llvm.org/D5695 for details.
This change does the following:
Enable lldb-gdbserver (llgs) usage for local-process Linux debugging.
To turn on local llgs debugging support, which is disabled by default, enable this setting:
(lldb) settings set platform.plugin.linux.use-llgs-for-local true
Adds a stream-based Dump() function to FileAction.
Pushes some platform methods that Linux (and FreeBSD) will want to share with MacOSX from PlatformDarwin into PlatformPOSIX.
Reviewed by Greg Clayton.
llvm-svn: 219457
Adds a test to verify that a thread resume request marks the thread as running
after doing the resume callback. This test fails without the corresponding
ThreadStateCoordinator.cpp change.
Fixes the code where that state was not maintained.
llvm-svn: 219412
Added tests and impl to make sure the following errors are reported:
* Notifying a created thread that we are already tracking.
* Notifying a thread death for a thread we don't know about.
llvm-svn: 218900
Now that ThreadStateCoordinator errors out on threads in unexpected states,
it has enough information to know which threads need stop requests fired
when we want to do a deferred callback on a thread's behalf. This change
adds a new method, CallAfterRunningThreadsStop(...), which no longer
takes a set of thread ids that require stop requests. It's much harder
to misuse this method and (with newer error logic) it's harder to
correctly use the original method. Expect the original method that takes
the set of thread ids to stop to disappear in the near future.
Adds several tests for CallAfterRunningThreadsStop().
llvm-svn: 218897
Added tests to verify that the coordinator signals an error if
the given thread to resume is unknown, and if the thread is through to
be running already.
Modified resume handling code to match tests.
llvm-svn: 218872
ThreadStateCoordinator changes:
* Most commands that run in the queue now take an error handler that
will be called with an error string if an error occurs during processing.
Errors generally stop the operation in progress. The errors are checked
at time of execution. This is intended to help flush out ptrace/waitpid/state management
issues as quickly as possible.
* Threads now must be known to the coordinator before stops can be reported,
resumes can be requested, thread deaths can be reported, or deferred stop
notifications can be made. Failure to know the thread will cause the coordinator
to call the error callback for the event being processed. Threads are introduced
to the system by the NotifyThreadCreate method.
* The NotifyThreadCreate method now takes the initial state of the thread being
introduces to the system. We no longer just assume the thread is running.
The test cases were cleaned up, too:
* A gtest test fixture is now used, which allows creating less verbose helper
methods that setup common pieces of callback code for some method invocations.
Net result: the tests are simpler to read and shorter to write.
llvm-svn: 218833
ThreadIDFunc => ThreadIDFunction
LogFunc => LogIDFunction
We try to avoid abbreviations/shortened names. Adjusted function parameter names
as well to replace _func with _function.
llvm-svn: 218773
There is a state transition that seems potentially buggy that I am capturing and
logging here, and including an explicit test to demonstrate expected behavior. See new test
for detailed description. Added logging around this area since, if we hit it, we
may have a usage bug, or a new state transition we really need to investigate.
This is around this scenario:
Thread C deferred stop notification awaiting thread A and thread B to stop.
Thread A stops.
Thread A requests resume.
Thread B stops.
Here we will explicitly signal the deferred stop notification after thread B
stops even though thread A is now resumed. Copious logging happens here.
llvm-svn: 218683
The thread resume block is executed in the normal flow of thread
state queued event processing. The tests verify that it is executed
when we track the thread to be stopped and skipped when we track
it to already be running.
llvm-svn: 218638
Also added a test for the reset handling. The reset/state clearing happens
as a processed queue event. The only diff vs. standard processing is that
the exec clears the queue before queueing the activity to clear internal state.
i.e. once we get an exec, we really stop doing any other queue-based activity.
llvm-svn: 218629
A new thread arriving while a pending signal notification
is outstanding will (1) add the new thread to the list of
stops expected before the deferred signal notification is
fired, (2) send a stop request for the new thread, and
(3) track the new thread as currently running.
llvm-svn: 218578
See http://reviews.llvm.org/D5495 for more details.
These are changes that are part of an effort to support building llgs, within the AOSP source tree, using the Android.mk
build system, when using the llvm/clang/lldb git repos from AOSP replaced with the experimental ones currently in
github.com/tfiala/aosp-{llvm,clang,lldb,compiler-rt}.
llvm-svn: 218568
Tested two pending stops before notification, where one of the pending stop
requirements was already known to be stopped.
Tested pending thread stop before notification, then reporting thread with
pending stop died and verifies pending notification is made.
llvm-svn: 218559
Glad I did - caught a bug where the auto variable was not a reference
to a set and instead was a copy. I need to review rules on that!
llvm-svn: 218558
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
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
* 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
Apparently, PEEKUSER/POKEUSER is something x86 specific, so I had to rework it for AArch64. This fixes assertion that occurs whenever lldb started on AArch64 device tried to read PC register (or any other register)
See http://reviews.llvm.org/D5232 for more details.
Change by Paul Osmialowski.
llvm-svn: 217691
* 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
This patch moves creates a thread abstraction that represents a
thread running inside the LLDB process. This is a replacement for
otherwise using lldb::thread_t, and provides a platform agnostic
interface to managing these threads.
Differential Revision: http://reviews.llvm.org/D5198
Reviewed by: Jim Ingham
llvm-svn: 217460
This makes sure that nothing that requires Python is being built
when the LLDB_DISABLE_PYTHON flag is being passed in.
It also changes a use of CPPFLAGS to CPP.Flags since the former is overridden
when external flags are passed in while the later is not. I'm not sure exactly
why LLDB_DISABLE_PYTHON is in CXXFLAGS rather than CPPFLAGS,
but cleaning that up is for another commit.
Differential Revision: http://reviews.llvm.org/D4918
llvm-svn: 217414
See http://reviews.llvm.org/D5108 for details.
This change does the following:
* eliminates the Process::GetUnixSignals() virtual method and replaces with a fixed getter.
* replaces the Process UnixSignals storage with a shared pointer.
* adds a Process constructor variant that can be passed the UnixSignalsSP. When the constructor without the UnixSignalsSP is specified, the Host's default UnixSignals is used.
* adds a host-specific version of GetUnixSignals() that is used when we need the host's appropriate UnixSignals variant.
* replaces GetUnixSignals() overrides in PlatformElfCore, ProcessGDBRemote, ProcessFreeBSD and ProcessLinux with code that appropriately sets the Process::UnixSignals for the process.
This change also enables some future patches that will enable llgs to be used for local Linux debugging.
llvm-svn: 216748
Yet another step toward ARM64 support. With this commit, lldb-gdbserver started on ARM64 target can be accessed by lldb running on desktop PC and it can process simple commands (like 'continue'). Still ARM64 support lacks NativeRegisterContextLinux_arm64.* code which waits to be implemented.
Based on similar files for Linux x86_64 and Darwin ARM64. Due to common code extraction from Darwin related files, lldb should be tested for any unexpected regression on Darwin ARM64 machines too.
See the following for more details:
http://reviews.llvm.org/D4580http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140825/012670.html
Change by Paul Osmialowski.
llvm-svn: 216737
This change:
* properly captures execs in NativeProcessLinux.
* clears out all non-main-thread thread metadata in NativeProcessLinux on exec.
* adds a DidExec() method to the NativeProcessProtocol delegate.
* clears out the auxv data cache when we exec (on Linux).
This is a small part of the llgs for local Linux debugging work going on here:
https://github.com/tfiala/lldb/tree/dev-llgs-local
I'm breaking it into small patches.
llvm-svn: 216670
I copied this originally based on what debugserver was doing. This appears to
be incorrect and unncessary for Linux. The LinuxSignals on the lldb side
don't look for these and therefore they get handled incorrectly.
Leaving the hook in place since I think darwin will continue to need to
translate those signal numbers.
llvm-svn: 216564
More specifically, this change can be summarized as follows:
1) Makes an lldbHostPosix library which contains code common to
all posix platforms.
2) Creates Host/FileSystem.h which defines a common FileSystem
interface.
3) Implements FileSystem.h in Host/windows and Host/posix.
4) Creates Host/FileCache.h, implemented in Host/common, which
defines a class useful for storing handles to open files needed
by the debugger.
Differential Revision: http://reviews.llvm.org/D4889
llvm-svn: 215775
FileAction was previously a nested class in ProcessLaunchInfo.
This led to some unfortunate style consequences, such as requiring
the AddPosixSpawnFileAction() funciton to be defined in the Target
layer, instead of the more appropriate Host layer. This patch
makes FileAction its own independent class in the Target layer,
and then moves AddPosixSpawnFileAction() into Host as a result.
Differential Revision: http://reviews.llvm.org/D4877
llvm-svn: 215649
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
These fix the broken debian lldb build, which is using g++ 4.7.2.
TypeFormat changes:
1. stopped using the C++11 "dtor = default;" construct.
The generated default destructor in the two derived classes wanted
them to have a different throws() semantic that was causing 4.7 to
fail to generate it. I switched these to empty destructors defined
in the .cpp file.
2. Switched the m_types map from an ordered map to an unordered_map.
g++ 4.7's c++ library supports the C++11 emplace() used by TypeFormat
but the same c++ library's map impl does not. Since TypeFormat didn't
look like it depended on ordering in the map, I just switched it to
a std::unordered_map.
NativeProcessLinux - g++ 4.7 chokes on lexing the "<::" in
static_cast<::pid_t>(wpid). g++ 4.8+ and clang are fine with it.
I just put a space in between the "<" and the "::" and that cleared
it up.
llvm-svn: 212681
See http://reviews.llvm.org/D4366 for details.
Change by Paul Paul Osmialowski
Today this is the only problem that I'm facing trying to cross-compile lldb for AArch64 using Linaro's toolchain.
PTRACE_GETREGS, PTRACE_SETREGS, PTRACE_GETFPREGS, PTRACE_SETFPREGS are not defined for AArch64
These things can be defined different ways for other architectures, e.g. for x86_64 Linux, asm/ptrace-abi.h defines them as preprocessor constants while sys/ptrace.h defines them in enum along with corresponding PT_* preprocessor constants
NativeProcessLinux.cpp includes sys/ptrace.h
To avoid accidental redefinition of enums with preprocessor constants, I'm proposing this patch which first checks for PT_* preprocessor constants then checks for PTRACE_* constants then when it still can not find them, it defines preprocessor constants.
Similar approach was already used for PTRACE_GETREGSET and PTRACE_SETREGSET constants; in this case however it was easier, since enum values in sys/ptrace.h and preprocessor constants shared all exactly the same names (e.g. there's no additional PT_GETREGSET name defined).
llvm-svn: 212225
There were a few places where we were not catching the possibility of negative
error codes in waitpid() calls. This change fixes those remaining after
the llgs branch fixes to ProcessMonitor.
Change by Shawn Best.
llvm-svn: 212107
Also moves NativeRegisterContextLinux* files into the Linux directory.
These, like NativeProcessLinux, should only be built on Linux or a cross
compiler with proper headers.
llvm-svn: 212074
This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64.
(More architectures coming soon).
Not every debugserver option is covered yet. Currently
the lldb-gdbserver command line can start unattached,
start attached to a pid (process-name attach not supported yet),
or accept lldb attaching and launching a process or connecting
by process id.
The history of this large change can be found here:
https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64
Until mid/late April, I was not sharing the work and continued
to rebase it off of head (developed via id tfiala@google.com). I switched over to
user todd.fiala@gmail.com in the middle, and once I went to github, I did
merges rather than rebasing so I could share with others.
llvm-svn: 212069
