summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
Commit message (Collapse)AuthorAgeFilesLines
* [NativeProcessLinux] Pass around threads by referencePavel Labath2015-08-241-11/+8
| | | | | | | | | | | | | | | | Summary: Most NPL private functions took (shared) pointers to threads as arguments. This meant that the callee could not be sure if the pointer was valid and so most functions were peppered with null-checks. Now, I move the check closer to the source, and pass around the threads as references (which are then assumed to be valid). Reviewers: tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12237 llvm-svn: 245831
* [NativeProcessLinux] Reduce the number of castsPavel Labath2015-08-211-6/+9
| | | | | | | | | | | | | | | Summary: NPL used to be peppered with casts of the NativeThreadProtocol objects into NativeThreadLinux. I move these closer to the source where we obtain these objects. This way, the rest of the code can assume we are working with the correct type of objects. Reviewers: ovyalov, tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12187 llvm-svn: 245681
* [NativeProcessLinux] Fix a bug in instruction-stepping over thread creationPavel Labath2015-08-201-33/+5
| | | | | | | | | | | | | | | | | | | | | | | Summary: There was a bug in NativeProcessLinux, where doing an instruction-level single-step over the thread-creation syscall resulted in loss of control over the inferior. This happened because after the inferior entered the thread-creation maintenance stop, we unconditionally performed a PTRACE_CONT, even though the original intention was to do a PTRACE_SINGLESTEP. This is fixed by storing the original state of the thread before the stop (stepping or running) and then performing the appropriate action when resuming. I also get rid of the callback in the ThreadContext structure, which stored the lambda used to resume the thread, but which was not used consistently. A test verifying the correctness of the new behavior is included. Reviewers: ovyalov, tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12104 llvm-svn: 245545
* Fix for build errors on arm-linux-gnueabi-gccOmair Javaid2015-08-091-1/+1
| | | | | | http://reviews.llvm.org/D11256 llvm-svn: 244419
* [NativeProcessLinux] Integrate MainLoopPavel Labath2015-07-211-33/+10
| | | | | | | | | | | | | | | | | | | Summary: This commit integrates MainLoop into NativeProcessLinux. By registering a SIGCHLD handler with the llgs main loop, we can get rid of the special monitor thread in NPL, which saves as a lot of thread ping-pong when responding to client requests (e.g. qThreadInfo processing time has been reduced by about 40%). It also makes the code simpler, IMHO. Reviewers: ovyalov, clayborg, tberghammer, chaoren Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11150 This is a resubmission of r242305 after it was reverted due to bad interactions with the stdio thread. llvm-svn: 242783
* Revert "[NativeProcessLinux] Integrate MainLoop"Pavel Labath2015-07-161-10/+33
| | | | | | This seems to be causing major slowdows on the android buildbot. Reverting while I investigate. llvm-svn: 242391
* [NativeProcessLinux] Integrate MainLoopPavel Labath2015-07-151-33/+10
| | | | | | | | | | | | | | | | Summary: This commit integrates MainLoop into NativeProcessLinux. By registering a SIGCHLD handler with the llgs main loop, we can get rid of the special monitor thread in NPL, which saves as a lot of thread ping-pong when responding to client requests (e.g. qThreadInfo processing time has been reduced by about 40%). It also makes the code simpler, IMHO. Reviewers: ovyalov, clayborg, tberghammer, chaoren Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11150 llvm-svn: 242305
* Avoid going through Platform when creating a NativeProcessProtocol instancePavel Labath2015-07-091-11/+7
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit avoids the Platform instance when spawning or attaching to a process in lldb-server. Instead, I have the server call a (static) method of NativeProcessProtocol directly. The reason for this is that I believe that NativeProcessProtocol should be decoupled from the Platform (after all, it always knows which platform it is running on, unlike the rest of lldb). Additionally, the kind of platform actions a NativeProcessProtocol instance is likely to differ greatly from the platform actions of the lldb client, so I think the separation makes sense. After this, the only dependency NativeProcessLinux has on PlatformLinux is the ResolveExecutable method, which needs additional refactoring. This is a resubmit of r241672, after it was reverted due to build failueres on non-linux platforms. Reviewers: ovyalov, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10996 llvm-svn: 241796
* Revert r241672, which breaks the OS X build by introducing a dependency onSean Callanan2015-07-081-7/+11
| | | | | | | | | | | | | | | | platform-specific symbols that are not implemented on OS X. The build error that caused this is Undefined symbols for architecture x86_64: "lldb_private::NativeProcessProtocol::Attach(unsigned long long, lldb_private::NativeProcessProtocol::NativeDelegate&, std::__1::shared_ptr<lldb_private::NativeProcessProtocol>&)", referenced from: lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::AttachToProcess(unsigned long long) in liblldb-core.a(GDBRemoteCommunicationServerLLGS.o) "lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&, lldb_private::NativeProcessProtocol::NativeDelegate&, std::__1::shared_ptr<lldb_private::NativeProcessProtocol>&)", referenced from: lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess() in liblldb-core.a(GDBRemoteCommunicationServerLLGS.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) llvm-svn: 241688
* Avoid going through Platform when creating a NativeProcessProtocol instancePavel Labath2015-07-081-11/+7
| | | | | | | | | | | | | | | | | | | | | Summary: This commit avoids the Platform instance when spawning or attaching to a process in lldb-server. Instead, I have the server call a (static) method of NativeProcessProtocol directly. The reason for this is that I believe that NativeProcessProtocol should be decoupled from the Platform (after all, it always knows which platform it is running on, unlike the rest of lldb). Additionally, the kind of platform actions a NativeProcessProtocol instance is likely to differ greatly from the platform actions of the lldb client, so I think the separation makes sense. After this, the only dependency NativeProcessLinux has on PlatformLinux is the ResolveExecutable method, which needs additional refactoring. Reviewers: ovyalov, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10996 llvm-svn: 241672
* [NativeProcessLinux] Refactor PtraceWrapperPavel Labath2015-06-301-2/+7
| | | | | | | | | | | | | | | | | Summary: This changes PtraceWrapper to return an Error, while the actual result is in an pointer parameter (instead of the other way around). Also made a couple of PtraceWrapper arguments default to zero. This arrangement makes a lot of the code much simpler. Test Plan: Tests pass on linux. It compiles on android arm64/mips64. Reviewers: chaoren, mohit.bhakkad Subscribers: tberghammer, aemerson, lldb-commits Differential Revision: http://reviews.llvm.org/D10808 llvm-svn: 241079
* [NativeProcessLinux] Use lambdas in DoOperation callsPavel Labath2015-06-261-26/+3
| | | | | | | | | | | | | | | | | | | Summary: This removes a lot of boilerplate, which was needed to execute monitor operations. Previously one needed do declare a separate class for each operation which would manually capture all needed arguments, which was very verbose. In addition to less code, I believe this also makes the code more readable, since now the implementation of the operation can be physically closer to the code that invokes it. Test Plan: Code compiles on x86, arm and mips, tests pass on x86 linux. Reviewers: tberghammer, chaoren Subscribers: aemerson, lldb-commits Differential Revision: http://reviews.llvm.org/D10694 llvm-svn: 240772
* Fetch object file load address if it isn't specified by the linkerTamas Berghammer2015-06-181-0/+3
| | | | | | Differential revision: http://reviews.llvm.org/D10490 llvm-svn: 240052
* Refactor many file functions to use FileSpec over strings.Chaoren Lin2015-05-291-16/+17
| | | | | | | | | | | | | | | | | Summary: This should solve the issue of sending denormalized paths over gdb-remote if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the server handle any denormalization. Reviewers: ovyalov, zturner, vharron, clayborg Reviewed By: clayborg Subscribers: tberghammer, emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D9728 llvm-svn: 238604
* [NativeProcessLinux] clean up #includesPavel Labath2015-05-291-6/+0
| | | | llvm-svn: 238551
* Move register reading form NativeProcessLinux to NativeRegisterContextLinux*Tamas Berghammer2015-05-261-51/+38
| | | | | | | | | | | | | | | | | This change reorganize the register read/write code inside lldb-server on Linux with moving the architecture independent code into a new class called NativeRegisterContextLinux and all of the architecture dependent code into the appropriate NativeRegisterContextLinux_* class. As part of it the compilation of the architecture specific register contexts are only compiled on the specific architecture because they can't be used in other cases. The purpose of this change is to remove a lot of duplicated code from the different register contexts and to remove the architecture dependent codes from the global NativeProcessLinux class. Differential revision: http://reviews.llvm.org/D9935 llvm-svn: 238196
* [NativeProcessLinux] Fix removal of temporary breakpointsPavel Labath2015-05-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: There was an issue in NPL, where we attempted removal of temporary breakpoints (used to implement software single stepping), while some threads of the process were running. This is a problem since we currently always use the main thread's ID in the removal ptrace call. Therefore, if the main thread was still running, the ptrace call would fail, and the software breakpoint would remain, causing all kinds of problems. This change removes the breakpoints after all threads have stopped. This fixes TestExitDuringStep on Android arm and can also potentially help in other situations, as previously the breakpoint would not get removed if the thread stopped for another reason. Test Plan: TestExitDuringStep passes, other tests remain unchanged. Reviewers: tberghammer Subscribers: tberghammer, aemerson, lldb-commits Differential Revision: http://reviews.llvm.org/D9792 llvm-svn: 237448
* LLDB build broke after applying patch http://reviews.llvm.org/D9706Omair Javaid2015-05-151-2/+1
| | | | | | This patch fixes the issue. llvm-svn: 237421
* This patch adds support for setting/clearing hardware watchpoints and ↵Omair Javaid2015-05-151-0/+11
| | | | | | | | breakpoints on AArch64 (Arm v8) 64-bit hardware. http://reviews.llvm.org/D9706 llvm-svn: 237419
* Remove handling of eStateStopped from NativeProcessLinux::ResumePavel Labath2015-05-121-29/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: NPL::Resume attempted to handle eStateStopped as a resume action. However: - GDBRemoteCommunicationServerLLGS (the only user of NPL) never sets this action - it could set this action in response to a vCont:t packet, but LLDB never produces this packet - gdb-remote protocol documentation says vCont:t packet is used only in non-stop mode, but LLDB does not support non-stop mode - even if LLDB supported non-stop mode, this implementation of eStateStopped does something different from what the spec says it should (according to spec, it should stop the specified thread, but this seems to want to stop all threads). Given the facts above, I believe we should remove this unused and untested code, as it probably doesn't even work and removing it makes the rest of the code noticably simpler. Reviewers: ovyalov, chaoren Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9657 llvm-svn: 237103
* [NativeProcessLinux] Remove event mutex and clean functions using itPavel Labath2015-05-121-44/+7
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Since the former-TSC events are now processed synchronously, there is no need for to protect them with a separate mutex - all the actions are now guarded by the big m_threads_mutex. With the mutex gone, the following functions, no longer have any purpose and were removed: NotifyThreadCreate: replaced by direct calls to ThreadWasCreated NotifyThreadStop: replaced by direct calls to ThreadDidStop NotifyThreadDeath: folded into StopTrackingThread ResetForExec: inlined as it consisted of a single line of code RequestThreadResume(AsNeeded): replaced by direct calls to ResumeThread StopThreads: removed, as it was never called Test Plan: tests continue to pass Reviewers: ovyalov, chaoren Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9603 llvm-svn: 237101
* [NativeProcessLinux] Remove double thread state accountingPavel Labath2015-05-111-42/+7
| | | | | | | | | | | | | | | | | | Summary: Now that all thread events are processed synchronously, there is no need to have separate records of whether a thread is running. This changes the (ever-dwindling) remains of the TSC to use NativeThreadLinux as the authoritative source of the state of threads. The rest of the ThreadContext we need has been moved to a member of NTL. Test Plan: ninja check-lldb continues to pass Reviewers: chaoren, ovyalov Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9562 llvm-svn: 236983
* [NativeProcessLinux] Remove the stop callbackPavel Labath2015-05-081-68/+33
| | | | | | | | | | | | | | | | | Summary: The stop callback is a remnant of the ThreadStateCoordinator. We don't need it now that TSC is gone, as we know exactly which function to call when threads stop. This also removes some stop-related functions, which were just forwarding calls to one another. Test Plan: ninja check-lldb continues to pass Reviewers: chaoren, ovyalov Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9531 llvm-svn: 236814
* [NativeProcessLinux] Remove logging and error callbacksPavel Labath2015-05-071-61/+21
| | | | | | | | | | | | | | | | Summary: These are remnants of the thread state coordinator, which are now unnecessary. I have basically inlined the callbacks. No functional change. Test Plan: Tests continue to pass. Reviewers: chaoren, vharron Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9343 llvm-svn: 236707
* [NativeProcessLinux] Remove the post-stop lambdaPavel Labath2015-05-061-35/+17
| | | | | | | | | | | | | | | | | | | | | | | Summary: The lambda was always calling SetState(eStateStopped) with small variations, so I have inlined the code. Given that we don't have the TSC anymore, I believe we don't need to be so generic. The only major change here is the way we choose a stop reason thread when we're interrupting a program on client request. Previously, we were setting a null stop reason for all threads and then fixing up the reason for one victim thread in the lambda. Now, I make sure the stop reason is set for the victim thread correctly in the first place. I also take the opportunity to rename CallAfter* functions into something more appropriate. Test Plan: All tests continue to pass. Reviewers: chaoren, vharron Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9321 llvm-svn: 236595
* [NativeProcessLinux] fold ThreadStateCoordinator into NPLPavel Labath2015-05-061-4/+222
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Since all TSC operations are now executed synchronously, TSC has become a little more than a messenger between different parts of NativeProcessLinux. Therefore, the reason for its existance has disappeared. This commit moves the contents of the TSC into the NPL class. This will enable us to remove all the boilerplate code in NPL (as it stands now, this is most of the class), which I plan to do in subsequent commits. Unfortunately, this also means we will lose the unit tests for the TSC. However, since the size of the TSC has diminished, the unit tests were not testing much at this point anyway, so it's not a big loss. No functional change. Test Plan: All tests continue to pass. Reviewers: vharron, chaoren Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9296 llvm-svn: 236587
* [NativeProcessLinux] Get rid of the thread state coordinator threadPavel Labath2015-05-051-14/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change removes the thread state coordinator thread by making all the operations it was performing synchronous. In order to prevent deadlock, NativeProcessLinux must now always call m_monitor->DoOperation with the m_threads_mutex released. This is needed because HandleWait callbacks lock the mutex (which means the monitor thread will block waiting on whoever holds the lock). If the other thread now requests a monitor operation, it will wait for the monitor thread do process it, creating a deadlock. To preserve this invariant I have introduced two new Monitor commands: "begin operation block" and "end operation block". They begin command blocks the monitor from processing waitpid events until the corresponding end command, thereby assuring the monitor does not attempt to acquire the mutex. Test Plan: Run the test suite locally, verify no tests fail. Reviewers: vharron, chaoren Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9227 llvm-svn: 236501
* Remove trap code from disassembly.Chaoren Lin2015-04-291-3/+6
| | | | | | | | | | | | | | | | | | | | Summary: NativeProcessProtocol uses ReadMemory internally for setting/checking breakpoints but also for generic memory reads (Handle_m), this change adds a ReadMemoryWithoutTrap for that purpose. Also fixes a bunch of misuses of addr_t as size/length. Test Plan: `disassemble` no longer shows the trap code. Reviewers: jingham, vharron, clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9330 llvm-svn: 236132
* [NativeProcessLinux] Add back synchronisation of thread create eventsPavel Labath2015-04-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Without the synchronisation between the two thread creation events the following case could happen: - threads A and B are running. A hits a breakpoint. We note that we want to stop B. - before we could stop it, B creates a new thread C, we get the stop notification for B, but we don't record C's existence yet. - we resume B - before we get the C notification, B stops again (e.g. hits a breakpoint, gets our SIGSTOP, etc.) - we see all known threads have stopped, and we notify LLDB - C notification comes, we note it's existence and resume it => we have an inconsistent state (LLDB thinks we've stopped, but C is running) I resolve this by doing a blocking wait for for the C notification when we get the creation notification on the parent (B) thread. This way the two events are synchronised, but we don't need to introduce the intermediate "launching" state which would complicate handling of thread states as all code would need to be aware of the third possible state. Test Plan: This is an obscure corner case, which I had not observed in practise, so I have no test for it. I have tested that this commit does not regress in existing tests though. Reviewers: chaoren, vharron Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9217 llvm-svn: 235969
* [NativeProcessLinux] Fix race condition during inferior thread creationPavel Labath2015-04-231-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following situation occured if we were stopping a process (due to breakpoint, watchpoint, ... hit) while a new thread was being created. - process has two threads: A and B. - thread A hits a breakpoint: we send a STOP signal to thread B and register a callback with ThreadStateCoordinator to send a stop notification after the thread stops. - thread B stops, but not due to the SIGSTOP, but on a thread creation event (of a new thread C). We are unaware of our desire to stop, so we queue ThreadStopped and RequestResume operations with TSC, so the thread can continue running. - TSC receives the ThreadStopped event, sees that all threads are stopped and fires the delayed stop notification. - immediately after that TSC gets the RequestResume operation, so it resumes the thread. At this point the state is inconsistent because LLDB thinks the process is stopped and will start issuing commands to it, but one of the threads is in fact running. Things eventually break. I address this problem by omitting the two TSC events altogether and Resuming the thread B directly. This way the short stop is invisible to the TSC and the delayed notification will not fire. We will fire the notification when we actually process the SIGSTOP on thread B. When we get the initial SIGSTOP for thread C, we also resume the thread and send a ThreadWasCreated message (is_stopped = false) to the TSC. This way, the TSC can stop the thread on its own and handle the stop event later. This way the state of the new thread is correctly handled as well (thanks Chaoren for the idea). This patch also removes the synchronisation between the thread creation notifications on threads B and C. The need for this synchronisation is unclear (the comments seem to hint that the new thread is "fully created" only after we process both events, but I have noticed no regressions in treating it as "created" even after just processing the initial C event), but it is a source for many kinds of obscure races, since it introduces a new thread state "Launching" and the rest of the code does not handle this state at all (what happens if we get a resume request from LLDB while this thread is launching? what happens if we get a stop request? etc.). This fixes the "spurious $O packet" problem in TestPrintStackTraces.py. However, the test remains disabled on i386 due to the VDSO issue. Test Plan: TestPrintStackTraces works on x86_64. No regressions in the rest of the test suite. Reviewers: vharron, chaoren Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9145 llvm-svn: 235579
* Fix signle stepping on arm when multiple thread is involvedTamas Berghammer2015-04-221-0/+6
| | | | | | | | | | | | On linux-arm we use software single stepping where setting the new breakpoint is only possible while the process is in stopped state. This CL moves the setup code for single stepping form the SigneStep operation into the Resum method to avoid an error when the process already started when we want to step one of the thread. Differential revision: http://reviews.llvm.org/D9108 llvm-svn: 235494
* NativeProcessLinux: Merge operation and monitor threadsPavel Labath2015-04-201-60/+8
| | | | | | | | | | | | | | | | | Summary: This commit moves the functionality of the operation thread into the new monitor thread. This is required to avoid a kernel race between the two threads and I believe it actually makes the code cleaner. Test Plan: Ran the test suite a couple of times, no regressions. Reviewers: ovyalov, tberghammer, vharron Subscribers: tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D9080 llvm-svn: 235304
* Use non-blocking waitpid in NativeProcessLinuxPavel Labath2015-04-171-8/+11
| | | | | | | | | | | | | | | | | | Summary: This is the first phase of the merging of Monitor and Operation threads in NativeProcessLinux (which is necessary since the two threads race inside Linux kernel). Here, I reimplement the Monitor thread do use non-blocking waitpid calls, which enables later addition of code from the operation thread. Test Plan: Ran the test suite a couple of times, no regressions detected. Reviewers: vharron, ovyalov, tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9048 llvm-svn: 235193
* Add single stepping logic for linux armTamas Berghammer2015-04-151-0/+4
| | | | | | | | | | | Linux arm don't support hardware stepping (neither mismatch breakpoints). This patch implement signle stepping with doing a software emulation of the next instruction and then setting a temporary breakpoint at the address where the thread will stop next. Differential revision: http://reviews.llvm.org/D8976 llvm-svn: 234987
* Fix breakpoint trap opcode detection for arm linuxTamas Berghammer2015-04-151-1/+1
| | | | llvm-svn: 234986
* Move several plugin to its own namespaceTamas Berghammer2015-03-311-27/+30
| | | | | | | | | | | | | Affected paths: * Plugins/Platform/Android/* * Plugins/Platform/Linux/* * Plugins/Platform/gdb-server/* * Plugins/Process/Linux/* * Plugins/Process/gdb-remote/* Differential revision: http://reviews.llvm.org/D8654 llvm-svn: 233679
* Fetch module specification from remote process alsoTamas Berghammer2015-03-241-1/+4
| | | | | | | | | | | | | Previously the remote module sepcification was fetched only from the remote platform. With this CL if we have a remote process then we ask it if it have any information from a given module. It is required because on android the dynamic linker only reports the name of the SO file and the platform can't always find it without a full path (the process can do it based on /proc/<pid>/maps). Differential revision: http://reviews.llvm.org/D8547 llvm-svn: 233061
* Report watchpoint hits during single stepping.Chaoren Lin2015-03-191-0/+9
| | | | | | | | | | | | | | | | | | Summary: Reorganized NativeProcessLinux::MonitorSIGTRAP to check for watchpoint hits on TRAP_TRACE. Added test for stepping over watchpoints. https://llvm.org/bugs/show_bug.cgi?id=22814 Reviewers: ovyalov, tberghammer, vharron, clayborg Subscribers: jingham, labath, lldb-commits Differential Revision: http://reviews.llvm.org/D8404 llvm-svn: 232784
* Add code to exit the NativeProcessLinux Monitor thread on androidTamas Berghammer2015-03-131-2/+2
| | | | | | | | | | This CL change the logic used to terminate the monitor thread of NativeProcessLinux to use a signal instead of pthread_cancel as pthread_cancel is not supported on android. Differential revision: http://reviews.llvm.org/D8205 llvm-svn: 232155
* Initialize ProcessGDBRemoteLog for LLGS to fix remote platform loggingRobert Flack2015-03-111-6/+0
| | | | | | | | This was previously initialized by ProcessGDBRemote::Initialize but lldb-server does not contain ProcessGDBRemote anymore so this needs to be initialized directly. Differential Revision: http://reviews.llvm.org/D8186 llvm-svn: 231966
* Initialize ProcessPOSIXLog by NativeProcessLinuxTamas Berghammer2015-03-061-0/+3
| | | | | | | | | | Previously it was initialized by ProcessLinux but lldb-server don't contain ProcessLinux anymore so it have to be initialized by NativeProcessLinux also. Differential revision: http://reviews.llvm.org/D8080 llvm-svn: 231482
* Prevent LLGS from crashing when exiting - make NativeProcessLinux to wait ↵Oleksiy Vyalov2015-02-191-6/+3
| | | | | | | | until ThreadStateCoordinator is fully stopped before entering ~NativeProcessLinux. http://reviews.llvm.org/D7692 llvm-svn: 229875
* Moving header files from source/Host/common to proper location.Chaoren Lin2015-02-031-1/+1
| | | | llvm-svn: 227929
* Modify ThreadStateCoodrinator in order to resume threads if stop wasn't ↵Chaoren Lin2015-02-031-0/+3
| | | | | | requested. llvm-svn: 227924
* Refactor ptrace commands in NativeProcessLinux to use Error as result return ↵Chaoren Lin2015-02-031-14/+14
| | | | | | type. llvm-svn: 227923
* Fix up NativeProcessLinux::Interrupt() to use thread state coordinator ↵Chaoren Lin2015-02-031-0/+3
| | | | | | mechanism. llvm-svn: 227917
* llgs: more work on thread stepping.Chaoren Lin2015-02-031-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | See https://github.com/tfiala/lldb/issues/75. Not fixed yet but continuing to push this further. Fixes: * Resume() now skips doing deferred notifications if we're doing a vCont;{c,C}. In this case, we're trying to start something up, not defer a stop notification. The default thread action stop mode pickup was triggering a stop because it had at least one stop, which was wrong in the case of a continue. (Bug introduced by previous change.) * Added a variant to ThreadStateCoordinator to specify a set of thread ids to be skipped when triggering stop notifications to non-stopped threads on a deferred signal call. For the case of a stepping thread, it is actually told to step (and is running) for a brief moment, but the thread state coordinator would think it needed to send the stepping thread a stop, which id doesn't need to do. This facility allows me to get around that cleanly. With this change, behavior is now reduced to something I think is essentially a different bug: * Doing a step into libc code from my code crashes llgs. * Doing a next out of a function in my own code crashes llgs. llvm-svn: 227912
* Get initial thread state coordinator integration working.Chaoren Lin2015-02-031-18/+25
| | | | | | | | | | | | | | | | | | | | * Fixed bug in run loop where run loop return enum was being treated erroneously like an int, causing the TSC event loop to terminate prematurely. * Added an explicit scope in NativeProcessLinux::Resume() for the threads lock lifetime. (This was likely unnecessary but is more explicit.) * Fixed a bug in ThreadStateCoordinator where resume execution was not updating the internal state about the thread assumed to be running now. I'll add a test and upstream this in a moment. * Added a verbose logging mechanism to event processing within ThreadStateCoordinator. It is currently enabled when the 'log enable lldb thread' is true upon inferior launch/attach. llvm-svn: 227909
* llgs: fixes to PTY/gdb-remote inferior stdout/stderr handling, logging addtions.Todd Fiala2014-10-111-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* llgs: fix Ctrl-C inferior interrupt handling to do the right thing.Todd Fiala2014-09-111-0/+16
| | | | | | | | | | | | | | | | * 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
OpenPOWER on IntegriCloud