summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target/Process.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert "LLDB: Fixed two race conditions when stopping private state thread"Pavel Labath2016-04-191-4/+8
| | | | | | This reverts commit r266733 as it causes a number of failures on linux buildbots. llvm-svn: 266736
* LLDB: Fixed two race conditions when stopping private state threadMarianne Mailhot-Sarrasin2016-04-191-8/+4
| | | | | | | | | | | | | | When stopping the private state thread, there was a race condition between the time the thread exits (resetting the HostThread object) and the time a Join was attempted, especially in the case of a timeout. The previous workaround of copying the HostThread object is not enough, since on a Reset the internal thread stuff gets nulled out regardless of which HostThread object actually has Reset called on it, resulting in an attempt to dereference a null pointer on the subsequent call to Join from the copy as well. Additionally, there was a race between the detach (called when stopping the process) and the stop itself, causing the stop to time out because it was waiting for the private state thread to see the stop state, but it had exited immediately after entering the detached state. Patch by cameron314 Differential Revision: http://reviews.llvm.org/D19122 llvm-svn: 266733
* Miscellaneous fixes for big-endian systemsUlrich Weigand2016-04-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a bunch of issues that show up on big-endian systems: - The gnu_libstdcpp.py script doesn't follow the way libstdc++ encodes bit vectors: it should identify the enclosing *word* and then access the appropriate bit within that word. Instead, the script simply operates on bytes. This gives the same result on little-endian systems, but not on big-endian. - lldb_private::formatters::WCharSummaryProvider always assumes wchar_t is UTF16, even though it could also be UTF8 or UTF32. This is mostly not an issue on little-endian systems, but immediately fails on BE. Fixed by checking the size of wchar_t like WCharStringSummaryProvider already does. - ClangASTContext::GetChildCompilerTypeAtIndex uses uint32_t to access the virtual base offset stored in the vtable, even though the size of this field matches the target pointer size according to the C++ ABI. Again, this is mostly not visible on LE, but fails on BE. - Process::ReadStringFromMemory uses strncmp to search for a terminator consisting of multiple zero bytes. This doesn't work since strncmp will stop already at the first zero byte. Use memcmp instead. Differential Revision: http://reviews.llvm.org/D18983 llvm-svn: 266313
* In GDBRemoteCommunicationClient::GetHostInfo, don't set theJason Molenda2016-04-071-1/+1
| | | | | | | | | | | | | | | | | | os to "ios" or "macosx" if it is unspecified. For environments where there genuinely is no os, we don't want to errantly convert that to ios/macosx, e.g. bare board debugging. Change PlatformRemoteiOS, PlatformRemoteAppleWatch, and PlatformRemoteAppleTV to not create themselves if we have an unspecified OS. Same problem - these are not appropriate platforms for bare board debugging environments. Have Process::Attach's logging take place if either process or target logging is enabled. <rdar://problem/25592378> llvm-svn: 265732
* Fix a bug in linux core file handlingPavel Labath2016-04-051-1/+13
| | | | | | | | | | | | | | | | | | | Summary: There was a bug in linux core file handling, where if there was a running process with the same process id as the id in the core file, the core file debugging would fail, as we would pull some pieces of information (ProcessInfo structure) from the running process instead of the core file. I fix this by routing the ProcessInfo requests through the Process class and overriding it in ProcessElfCore to return correct data. A (slightly convoluted) test is included. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18697 llvm-svn: 265391
* Add a DiagnosticManager replace error streams in the expression parser.Sean Callanan2016-03-191-32/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to do a better job presenting errors that occur when evaluating expressions. Key to this effort is getting away from a model where all errors are spat out onto a stream where the client has to take or leave all of them. To this end, this patch adds a new class, DiagnosticManager, which contains errors produced by the compiler or by LLDB as an expression is created. The DiagnosticManager can dump itself to a log as well as to a string. Clients will (in the future) be able to filter out the errors they're interested in by ID or present subsets of these errors to the user. This patch is not intended to change the *users* of errors - only to thread DiagnosticManagers to all the places where streams are used. I also attempt to standardize our use of errors a bit, removing trailing newlines and making clients omit 'error:', 'warning:' etc. and instead pass the Severity flag. The patch is testsuite-neutral, with modifications to one part of the MI tests because it relied on "error: error:" being erroneously printed. This patch fixes the MI variable handling and the testcase. <rdar://problem/22864976> llvm-svn: 263859
* Only try to load the OS plug-in after a shared library load if we don't ↵Greg Clayton2016-03-151-1/+4
| | | | | | | | already have one. <rdar://problem/24162686> llvm-svn: 263602
* Change over the broadcaster/listener process to hold shared or weak pointersJim Ingham2016-03-071-57/+61
| | | | | | | | | | | | | | to each other. This should remove some infrequent teardown crashes when the listener is not the debugger's listener. Processes now need to take a ListenerSP, not a Listener&. This required changing over the Process plugin class constructors to take a ListenerSP, instead of a Listener&. Other than that there should be no functional change. <rdar://problem/24580184> CrashTracer: [USER] Xcode at …ework: lldb_private::Listener::BroadcasterWillDestruct + 39 llvm-svn: 262863
* Fix MSVC build failure in source/Target/Process.cpp.Eugene Zelenko2016-03-011-1/+1
| | | | | | Will be good idea to introduce macro/constexpr for NULL thread_result_t. llvm-svn: 262287
* Fix Clang-tidy modernize-use-nullptr warnings in some files in ↵Eugene Zelenko2016-03-011-194/+182
| | | | | | source/Target/Process.cpp; other minor fixes. llvm-svn: 262281
* Make LLDB safer to use with respect to the global destructor chain.Greg Clayton2016-02-261-4/+5
| | | | llvm-svn: 262090
* Make sure to #include <atomic> for the std::atomic<bool> that was recently ↵Greg Clayton2016-02-261-0/+1
| | | | | | added. llvm-svn: 262055
* Make sure the Target, Process and Thread GetGlobalProperties() static ↵Greg Clayton2016-02-261-2/+6
| | | | | | | | methods are thread safe. <rdar://problem/22595283> llvm-svn: 262053
* The IOHandlerProcessSTDIO is the _only_ IOHandler that gets pushed and ↵Greg Clayton2016-02-261-3/+22
| | | | | | | | | | | | | | popped from functions that are run due to something that is NOT input from the user. All other IOHandler objects result from input from the user. An issue rose up where if a command caused the process to resume and stop and process state changed, where state changed Event objects were broadcast, it would cause the IOHandlerProcessSTDIO to have its IOHandlerProcessSTDIO::Cancel() function called. This used to always write a byte to the control pipe (IOHandlerProcessSTDIO::m_pipe) even if the IOHandlerProcessSTDIO::Run() was never called. What would happen is: (lldb) command_that_steps_process_thousands_of_times As the "command_that_steps_process_thousands_of_times" could be a python command that resumed the process thousands of times and in doing so the IOHandlerProcessSTDIO would get pushed when the process resumed, and popped when it stoppped, causing the call to IOHandlerProcessSTDIO::Cancel(). Since the IOHandler thread is currently in IOHandlerEditline::Run() for the command interpreter handling the "command_that_steps_process_thousands_of_times" command, IOHandlerProcessSTDIO::Run() would never get called, even though the IOHandlerProcessSTDIO is on the top of the stack. This caused the command pipe to keep getting 1 bytes written each time the IOHandlerProcessSTDIO::Cancel() was called and eventually we will deadlock since the write buffer is full. The fix here is to make sure we are in IOHandlerProcessSTDIO::Run() before we write anything to the command pipe, and just call SetIsDone(true) if we are not. <rdar://problem/22361364> llvm-svn: 262040
* Add -Wimplicit-fallthrough command line option to clang inJason Molenda2016-02-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | the xcode project file to catch switch statements that have a case that falls through unintentionally. Define LLVM_FALLTHROUGH to indicate instances where a case has code and intends to fall through. This should be in llvm/Support/Compiler.h; Peter Collingbourne originally checked in there (r237766), then reverted (r237941) because he didn't have time to mark up all the 'case' statements that were intended to fall through. I put together a patch to get this back in llvm http://reviews.llvm.org/D17063 but it hasn't been approved in the past week. I added a new lldb-private-defines.h to hold the definition for now. Every place in lldb where there is a comment that the fall-through is intentional, I added LLVM_FALLTHROUGH to silence the warning. I haven't tried to identify whether the fallthrough is a bug or not in the other places. I haven't tried to add this to the cmake option build flags. This warning will only work for clang. This build cleanly (with some new warnings) on macosx with clang under xcodebuild, but if this causes problems for people on other configurations, I'll back it out. llvm-svn: 260930
* Fix a little threading thinko in StartPrivateStateThread - don't pass stack ↵Jim Ingham2016-02-041-4/+5
| | | | | | | | | | variables as args to a pthread_create function... <rdar://problem/24485206> llvm-svn: 259738
* Revert r258546.Saleem Abdulrasool2016-01-261-1/+0
| | | | | | | | | Seems that the patch was rebased on top of another change which obsoleted the change but wasnt caught. Thanks to nbjoerg for pointing this out! llvm-svn: 258821
* Silence -Wreturn-type warningsSaleem Abdulrasool2016-01-221-0/+1
| | | | | | | | Address a couple of instances of -Wreturn-type warning from GCC. The switches are covered, add an llvm_unreachable to the end of the functions to silence the warning. NFC. llvm-svn: 258546
* Placate MVSC after my last commit.Davide Italiano2016-01-191-6/+2
| | | | | | | | Zachary introduced the 'default' case explicitly to placate a warning in the Microsoft compiler but that broke clang with -Werror. The new code should keep both compilers happy. llvm-svn: 258212
* [Process] Remove dead code. All the switch cases are already covered.Davide Italiano2016-01-191-2/+0
| | | | llvm-svn: 258199
* Fix some compiler warnings with MSVC 2015.Zachary Turner2016-01-131-0/+2
| | | | llvm-svn: 257671
* Re-apply r257117 (reverted in r257138 temporarily),Jason Molenda2016-01-081-0/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with the one change that ThreadPlanStepOut::ThreadPlanStepOut will now only advance the return address breakpoint to the end of a source line, if we have source line debug information. It will not advance to the end of a Symbol if we lack source line information. This, or the recognition of the LEAVE instruction in r257209, would have fixed the regression that Siva was seeing. Both were good changes, so I've made both. Original commit message: Performance improvement: Change lldb so that it puts a breakpoint on the first branch instruction after a function return (or the end of a source line), instead of a breakpoint on the return address, to skip an extra stop & start of the inferior process. I changed Process::AdvanceAddressToNextBranchInstruction to not take an optional InstructionList argument - no callers are providing a cached InstructionList today, and if this function was going to do that, the right thing to do would be to fill out / use a DisassemblerSP which is a disassembler with the InstructionList for this address range. http://reviews.llvm.org/D15708 <rdar://problem/23309838> llvm-svn: 257210
* Revert r257117 "Performance improvement: Change lldb so that itJason Molenda2016-01-081-62/+0
| | | | | | | | puts a breakpoint" it is causing a regression in the TestStepNoDebug test case on ubuntu 14.04 with gcc 4.9.2. Thanks for the email Siva. I'll recommit when I've figured out the regression. llvm-svn: 257138
* Performance improvement: Change lldb so that it puts a breakpointJason Molenda2016-01-081-0/+62
| | | | | | | | | | | | | | | | | | | on the first branch instruction after a function return (or the end of a source line), instead of a breakpoint on the return address, to skip an extra stop & start of the inferior process. I changed Process::AdvanceAddressToNextBranchInstruction to not take an optional InstructionList argument - no callers are providing a cached InstructionList today, and if this function was going to do that, the right thing to do would be to fill out / use a DisassemblerSP which is a disassembler with the InstructionList for this address range. http://reviews.llvm.org/D15708 <rdar://problem/23309838> llvm-svn: 257117
* Fix a typo in Process.cppPavel Labath2016-01-051-1/+1
| | | | llvm-svn: 256852
* Set the minimum stack size for private state thread to 8MBKate Stone2015-12-171-1/+1
| | | | | | Demangling complex Boost symbols can exhaust the default stack size. In practice, any thread that calls into LLDB functionality that touches symbols runs this risk. Guaranteeing a reasonable minimum for our own private state thread addressees some known scenarios debugging processes that make use of cpp-netlib. llvm-svn: 255868
* When printing warnings, the repeat_key should beSean Callanan2015-12-091-1/+1
| | | | | | | const void * because the data is never accessed, the pointer is the only useful piece of data. llvm-svn: 255090
* Recommit "Fix race during process interruption"Pavel Labath2015-12-071-113/+100
| | | | | | | | This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the original commit, where we would incorrectly interrupt the process if the interrupt request came just as we were about to send the stopped event to the public. llvm-svn: 254902
* Add a newline at the end of this fileEnrico Granata2015-12-031-1/+1
| | | | llvm-svn: 254666
* Fix "process load/unload" on androidTamas Berghammer2015-12-021-217/+22
| | | | | | | | | | | On android the symbols exposed by libdl (dlopen, dlclose, dlerror) prefixed by "__dl_". This change moves the handling of process load/unload to the platform object and override it for android to handle the special prefix. Differential revision: http://reviews.llvm.org/D11465 llvm-svn: 254504
* Revert "Fix race during process interruption"Pavel Labath2015-12-011-88/+111
| | | | | | The android buildbot gets quite flaky after this change. I'm reverting it while I investigate. llvm-svn: 254430
* Fix race during process interruptionPavel Labath2015-12-011-111/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The following situation was occuring in TestAttachResume: - we did a "continue" from a breakpoint (which involves a private start-stop to step over the breakpoint) - after receiving the stop-reply from the step-over, we issue a "detach" (which requires a process interrupt) - at this moment, the public state is "running", private state is "about-to-be-stopped" (the stopped event was broadcast, but it was not received yet) - StopForDestroyOrDetach (public thread) notes the public state is running, sends an interrupt request to the private thread - private thread gets the eBroadcastBitInterrupt (before the eStateStopped message), and asks the process plugin to stop (via Halt()) - process plugin says it has nothing to do as the process is already stopped - private thread shrugs and carries on. receives the stop event, restores the breakpoint and resumes the process. - after a while, the public thread times out and says it failed to stop the process This patch does the following: - splits Halt() into two functions, private and public, their usage depends on the context - public Halt(): sends eBroadcastBitInterrupt to the private thread and waits for the Stop event - HaltPrivate(): asks the plugin to stop and makes a note that the halt was requested. When the next stop event comes it sets the interrupt flag on it. - removes HijackPrivateProcessEvents(), as the only user (old Halt()) has gone away - removes the m_currently_handling_event hack, as the new Halt() does not need it - adds a use_run_lock parameter to public Halt() and WaitForProcessToStop(). This was needed because RunThreadPlan uses Halt() while holding the run lock and we don't want Halt() to take it away from him. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14989 llvm-svn: 254403
* Add support for the new (added last week) llvm::Triple::WatchOS and ::TvOSJason Molenda2015-11-051-0/+23
| | | | | | | | | | in places where we check for Triple::IOS. They're mostly the same as far as lldb is conerned. . Also add a base cass implementation for Process::IsAlive - Greg added this last year but it didn't get upstreamed. llvm-svn: 252227
* Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. ↵Jim Ingham2015-11-041-0/+12
| | | | | | | | Zero out the Expression ResultVariable so it's in a known initial state. llvm-svn: 252072
* Fix an issue where LLDB would truncate summaries for string types without ↵Enrico Granata2015-11-041-1/+1
| | | | | | producing any evidence thereof llvm-svn: 252018
* Fix race during process detachPavel Labath2015-11-031-34/+31
| | | | | | | | | | | | | | | | Summary: The code which was preventing the usage of the OS plugin while detach is in progress also prevented us to update the thread list correctly. This resulted in an empty thread list, which confused the detaching logic. Change the condition do only do what it says (disable the usage of the OS plugin). Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14201 llvm-svn: 251932
* Fix Clang-tidy modernize-use-override warnings in source/Target; other minor ↵Eugene Zelenko2015-10-231-68/+17
| | | | | | fixes. llvm-svn: 251134
* Increase default memory cache line size for androidPavel Labath2015-10-201-0/+7
| | | | | | | | | | | | | | | | Summary: ADB packets have a maximum size of 4k. This means the size of memory reads does not affect speed too much (as long as it fits in one packet). Therefore, I am increasing the default memory read size for android to 2k. This value is used only if the user has not modified the default memory-cache-line-size setting. Reviewers: clayborg, tberghammer Subscribers: tberghammer, danalbert, srhines, lldb-commits Differential Revision: http://reviews.llvm.org/D13812 llvm-svn: 250814
* Make uses of /dev/null portable across OSes.Zachary Turner2015-10-141-1/+2
| | | | | | | | | Most platforms have "/dev/null". Windows has "nul". Instead of hardcoding the string /dev/null at various places, make a constant that contains the correct value depending on the platform, and use that everywhere instead. llvm-svn: 250331
* ArchSpec: fix unintentional promotion of unspecified unknowns to specified ↵Todd Fiala2015-10-131-5/+13
| | | | | | | | | | | | | | | | | | | | | unknowns * ArchSpec::MergeFrom() would erroneously promote an unspecified unknown to a specified unknown when both the ArchSpec and the merged in ArchSpec were both unspecified unknowns. This no longer happens, which fixes issues with global module cache lookup in some situations. * Added ArchSpec::DumpTriple(Stream&) that now properly prints unspecified unknowns as '*' and specified unknows as 'unknown'. This makes it trivial to tell the difference between the two. Converted printing code over ot using DumpTriple() rather than building from scratch. * Fixed up a couple places that were not guaranteeing that an unspecified unknown was recorded as such. llvm-svn: 250253
* Fix a misunderstanding of the ThreadPlan::OkayToDiscard flag in ↵Jim Ingham2015-10-121-9/+84
| | | | | | | | | | | | | InferiorCallPOSIX. It was set to true, but all plans run by RunThreadPlan need to have this set to false so they will return control to RunThreadPlan without consulting plans higher on the stack. Since this seems like a common error, I also modified RunThreadPlan to enforce this behavior. <rdar://problem/22543166> llvm-svn: 250084
* Resumbit "Fix race condition during process detach"Pavel Labath2015-10-071-40/+40
| | | | | | | This is a resubmission of r248371. It also incorporates the process event hijack patch by Kyrill Lapshin in D12968. llvm-svn: 249554
* Revert "Fix race condition during process detach"Pavel Labath2015-09-281-34/+40
| | | | | | This fix is not correct on its own until D12968 is resolved. Will resumbit once that is done. llvm-svn: 248702
* Fix race condition during process detachPavel Labath2015-09-231-40/+34
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The following situation occured in TestAttachResume: The inferior was stoped at a breakpoint and we did a continue, immediately followed by a detach. Since there was a trap instruction under the IP, the continue did a step-over-breakpoint before resuming the inferior for real. In some cases, the detach command was executed between these two events (after the step-over stop, but before continue). Here, public state was running, but private state was stopped. This caused a problem because HaltForDestroyOrDetach was checking the public state to see whether it needs to stop the process (call Halt()), but Halt() was checking the private state and concluded that there is nothing for it to do. Solution: Instead of Halt() call SendAsyncInterrupt(), which will then cause Halt() to be executed in the context of the private state thread. I also rename HaltForDestroyOrDetach to reflect it does not call halt directly. Reviewers: jingham, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13056 llvm-svn: 248371
* Add an OperatingSystem plugin to support goroutinesRyan Brown2015-09-161-0/+2
| | | | | | | | | | The Go runtime schedules user level threads (goroutines) across real threads. This adds an OS plugin to create memory threads for goroutines. It supports the 1.4 and 1.5 go runtime. Differential Revision: http://reviews.llvm.org/D5871 llvm-svn: 247852
* This patch makes Clang-independent base classes for all the expression types ↵Jim Ingham2015-09-151-13/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | that lldb currently vends. Before we had: ClangFunction ClangUtilityFunction ClangUserExpression and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression base class, and three pure virtual implementations for the Expression kinds: FunctionCaller UtilityFunction UserExpression You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage. The Target will then consult all the registered TypeSystem plugins, and if the type system that matches the language can make an expression of that kind, it will do so and return it. Because all of the real expression types need to communicate with their ExpressionParser in a uniform way, I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types. Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs. The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions. Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary. llvm-svn: 247720
* Fix logging messagePavel Labath2015-09-031-1/+1
| | | | llvm-svn: 246776
* Fix rare failure in TestProcessIOPavel Labath2015-09-031-6/+5
| | | | | | | | | | | | | | | | | | | | | Summary: There was a race condition in Process class, where we would not wait for process stdout to propagate fully before we would shut down the connection (repro case: slow down the stdio thread by placing a sleep right at the end of the while loop in Communication::ReadThread). The Process class already tried to solve this problem by synchronizing with the read thread in Process::ShouldBroadcastEvent, but unfortunately the connection got closed before that in Process::SetExitStatus. I solve this issue by delaying the connection shutdown until we get a chance to process the event and synchronize. Alternatively, I could have moved the synchronization point to an earlier point in SetExitStatus, but it seems safer to delay the shutdown until other things get a chance to notice the process has exited. Reviewers: clayborg, ovyalov Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12558 llvm-svn: 246753
* Have the Process hold a weak_ptr to the Target.Zachary Turner2015-09-011-49/+49
| | | | llvm-svn: 246578
* Make ProcessGDBRemote get a //copy// of platform Unix signals.Chaoren Lin2015-09-011-1/+1
| | | | | | | | | | | | Summary: Update to http://reviews.llvm.org/rL243618. Reviewers: jaydeep, clayborg Subscribers: labath, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D12420 llvm-svn: 246557
OpenPOWER on IntegriCloud