Summary:
NetBSD ships with NativeProcessNetBSD inherited from NativeProcessProtocol.
Link Plugins/Process/gdb-remote with lldbPluginProcessNetBSD in order to resolve
correctly the linking to Launch and Attach from the NetBSD plugin.
Sponsored by <The NetBSD Foundation>
Reviewers: kettenis, labath, emaste, joerg
Reviewed By: labath, emaste
Subscribers: mgorny, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31231
llvm-svn: 298524
Summary:
GetAuxvData was causing dependencies from host to target and linux
process modules. It also does not fit netbsd use case, as there we can
only read the auxiliary vector with ptrace, which is better done in the
process plugin, with the other ptrace calls.
I resolve these issues by moving the freebsd and linux versions into the
relevant process plugins. In case of linux, this required adding an
interface in NativeProcessProtocol. The empty definitions on other
platforms can simply be removed.
To get the code compiling I had to add ProcessGdbRemote -> ProcessLinux
dependency, which was not caught before because we depended on it
transitively.
Reviewers: zturner, emaste
Subscribers: srhines, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D31031
llvm-svn: 298066
Resumbitting the commit after fixing the following problems:
- broken unit tests on windows: incorrect gtest usage on my part (TEST vs. TEST_F)
- the new code did not correctly handle the case where we went to interrupt the process, but it
stopped due to a different reason - the interrupt request would remain queued and would
interfere with the following "continue". I also added a unit test for this case.
This reapplies r277156 and r277139.
llvm-svn: 278118
This reverts commit r277139, because:
- broken unittest on windows (likely typo on my part)
- seems to break TestCallThatRestart (needs investigation)
llvm-svn: 277154
SendContinuePacketAndWaitForResponse was huge function with very complex interactions with
several other functions (SendAsyncSignal, SendInterrupt, SendPacket). This meant that making any
changes to how packet sending functions and threads interact was very difficult and error-prone.
This change does not add any functionality yet, it merely paves the way for future changes. In a
follow-up, I plan to add the ability to have multiple query packets in flight (i.e.,
request,request,response,response instead of the usual request,response sequences) and use that
to speed up qModuleInfo packet processing.
Here, I introduce two special kinds of locks: ContinueLock, which is used by the continue thread,
and Lock, which is used by everyone else. ContinueLock (atomically) sends a continue packet, and
blocks any other async threads from accessing the connection. Other threads create an instance of
the Lock object when they want to access the connection. This object, while in scope prevents the
continue from being send. Optionally, it can also interrupt the process to gain access to the
connection for async processing.
Most of the syncrhonization logic is encapsulated within these two classes. Some of it still
had to bleed over into the SendContinuePacketAndWaitForResponse, but the function is still much
more manageable than before -- partly because of most of the work is done in the ContinueLock
class, and partly because I have factored out a lot of the packet processing code separate
functions (this also makes the functionality more easily testable). Most importantly, there is
none of syncrhonization code in the async thread users -- as far as they are concerned, they just
need to declare a Lock object, and they are good to go (SendPacketAndWaitForResponse is now a
very thin wrapper around the NoLock version of the function, whereas previously it had over 100
lines of synchronization code). This will make my follow up changes there easy.
I have written a number of unit tests for the new code and I have ran the test suite on linux and
osx with no regressions.
Subscribers: tberghammer
Differential Revision: https://reviews.llvm.org/D22629
llvm-svn: 277139
Summary:
This doesn't exist in other LLVM projects any longer and doesn't
do anything.
Reviewers: chaoren, labath
Subscribers: emaste, tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D12586
llvm-svn: 246749
- generate-vers.pl has to be called by cmake to generate the version number
- parallel builds not yet supported; dependency on clang must be explicitly specified
Tested on Linux.
- Building on Mac will require code-signing logic to be implemented.
- Building on Windows will require OS-detection logic and some selective directory inclusion
Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir
who ported them to Linux!
llvm-svn: 175795
Kamil Rytarowski