summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target/Process.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Feedback from Jim: Change the "optimized code" warning to be entirelyJason Molenda2015-08-101-0/+14
| | | | | | | | | | | | contained within Process so that we won't be duplicating the warning message if other parts of the code want to issue the message. Change Process::PrintWarning to be a protected method - the public method will be the PrintWarningOptimization et al. Also, Have Thread::FunctionOptimizationWarning shortcut out if the warnings have been disabled so that we don't (potentially) compute parts of the SymbolContext unnecessarily. llvm-svn: 244436
* Second part of indicating when the user is stopped in optimized code.Jason Molenda2015-08-061-1/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The first part was in r243508 -- the extent of the UI changes in that patchset was to add "[opt]" to the frame-format when a stack frame was built with optimized code. In this change, when a stack frame built with optimization is selected, a message will be printed to the async output channel -- opt1.c was compiled with optimization - stepping may behave oddly; variables may not be available. The warning will be only be printed once per source file in a debug session. These warnings may be disabled by settings set target.process.optimization-warnings false Internally, a new Process::PrintWarning() method has been added for warnings that we want to print only once to the user. It takes a type of warning (currently only eWarningsOptimization) and an object pointer (CompileUnit*) - the warning will only be printed once for a given object pointer value. This is a bit of a prototype of this change - I think we will be tweaking it more in the future. But I wanted to land this and see how it goes. Advanced users will find these warnings unnecessary noise and will quickly disable them - but anyone who maintains a debugger knows that debugging optimized code, without realizing it, is a constant source of confusion and frustation for more typical debugger users. I imagine there will be more of these "warn once per whatever" style warnings that we will want to add in the future and we'll need to come up with a better way for enabling/disabling them. But I'm not srue what form that warning settings should take and I didn't want to code up something that we regret later, so for now I just added another process setting for this one warning. <rdar://problem/19281172> llvm-svn: 244190
* Add some initial logging for when lldb is searching for binaries,Jason Molenda2015-07-251-0/+5
| | | | | | | | | dSYMs, or reading binaries out of memory to the 'Host' log channel. There's more to be done here, both for Mac and for other platforms, but the initial set of new loggings are useful enough to check in at this point. llvm-svn: 243200
* Add UNUSED_IF_ASSERT_DISABLED and apply it.Bruce Mitchener2015-07-241-1/+1
| | | | | | | | | | | | | | | Summary: This replaces (void)x; usages where they x was subsequently involved in an assertion with this macro to make the intent more clear. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11451 llvm-svn: 243074
* Fix warnings.Bruce Mitchener2015-07-221-0/+1
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11404 llvm-svn: 242913
OpenPOWER on IntegriCloud