summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target/Process.cpp
Commit message (Collapse)AuthorAgeFilesLines
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-6053/+5555
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Fix build breakage in r280692Pavel Labath2016-09-061-1/+1
| | | | | | | | | The commit introduced an array of const objects, which libstdc++ does not like. Make the object non-const. Also fix a compiler warning while I'm in there. llvm-svn: 280697
* Added the "frame diagnose" command and use its output to make crash info better.Sean Callanan2016-09-061-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When a process stops due to a crash, we get the crashing instruction and the crashing memory location (if there is one). From the user's perspective it is often unclear what the reason for the crash is in a symbolic sense. To address this, I have added new fuctionality to StackFrame to parse the disassembly and reconstruct the sequence of dereferneces and offsets that were applied to a known variable (or fuction retrn value) to obtain the invalid pointer. This makes use of enhancements in the disassembler, as well as new information provided by the DWARF expression infrastructure, and is exposed through a "frame diagnose" command. It is also used to provide symbolic information, when available, in the event of a crash. The algorithm is very rudimentary, and it needs a bunch of work, including - better parsing for assembly, preferably with help from LLVM - support for non-Apple platforms - cleanup of the algorithm core, preferably to make it all work in terms of Operands instead of register/offset pairs - improvement of the GetExpressioPath() logic to make prettier expression paths, and - better handling of vtables. I welcome all suggestios, improvements, and testcases. llvm-svn: 280692
* Remove unused variables.Zachary Turner2016-08-311-2/+0
| | | | | | Patch by Taras Tsugrii llvm-svn: 280283
* Fix mismatched new/free in Process:RunPrivateStateThreadPavel Labath2016-08-241-3/+2
| | | | | | NFC llvm-svn: 279627
* Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala2016-08-191-1/+154
| | | | | | | | | | | | Take 2, with missing cmake line fixed. Build tested on Ubuntu 14.04 with clang-3.6. See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279202
* Revert "Add StructuredData plugin type; showcase with new DarwinLog feature"Todd Fiala2016-08-191-154/+1
| | | | | | This reverts commit 1d885845d1451e7b232f53fba2e36be67aadabd8. llvm-svn: 279200
* Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala2016-08-191-1/+154
| | | | | | | | | See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279198
* Decoupled Options from CommandInterpreter.Todd Fiala2016-08-111-3/+11
| | | | | | | | | | | | | | | | Options used to store a reference to the CommandInterpreter instance in the base Options class. This made it impossible to parse options independent of a CommandInterpreter. This change removes the reference from the base class. Instead, it modifies the options-parsing-related methods to take an ExecutionContext pointer, which the options may inspect if they need to do so. Closes https://reviews.llvm.org/D23416 Reviewers: clayborg, jingham llvm-svn: 278440
* Centralize all select() calls into one place so that we can take advantage ↵Greg Clayton2016-08-101-15/+11
| | | | | | | | | of system specific optimizations to deal with more file descriptors than FD_SETSIZE on some systems. <rdar://problem/25325383> https://reviews.llvm.org/D22950 llvm-svn: 278299
* Fixup r277011 - wrong use of infinite timeoutPavel Labath2016-07-291-1/+1
| | | | | | | The commit accidentally switched a timed wait on a condition variable into an infinite timeout. Change that back. Android tests were timeing out without this. llvm-svn: 277133
* Clean up vestigial remnants of locking primitivesSaleem Abdulrasool2016-07-281-89/+48
| | | | | | | | | | | | | | | | This finally removes the use of the Mutex and Condition classes. This is an intricate patch as the Mutex and Condition classes were tied together. Furthermore, many places had slightly differing uses of time values. Convert timeout values to relative everywhere to permit the use of std::chrono::duration, which is required for the use of std::condition_variable's timeout. Adjust all Condition and related Mutex classes over to std::{,recursive_}mutex and std::condition_variable. This change primarily comes at the cost of breaking the TracingMutex which was based around the Mutex class. It would be possible to write a wrapper to provide similar functionality, but that is beyond the scope of this change. llvm-svn: 277011
* Check both private & public states to decide if you need to halt before killing.Jim Ingham2016-07-261-1/+4
| | | | | | | | | | We were just checking the public state, but that meant if you were hung in a long running hand-called function, we wouldn't know to interrupt the process, and we would not succeed in killing it. <rdar://problem/24805082> llvm-svn: 276795
* Fix a race on process exitPavel Labath2016-07-121-8/+0
| | | | | | | | | | | | | | | | | | | | | Summary: Process::SetExitStatus was popping the process io handler and resetting m_process_input_reader shared pointer, which is not a safe thing to do as the function is called asynchronously and other threads may be accessing the member variable. (E.g. if the process terminates really quickly, the private state thread might only be in the process of pushing the handler on the stack. Sometimes, this leads to deadlock, as the shared pointer's state gets corrupted by the concurrent access. Since the IOHandler will be popped anyway in Process:HandleProcessStateChangedEvent when the exited event gets processed, doing the same in SetExitStatus seems to be unnecessary. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D22209 llvm-svn: 275165
* Implement GetMemoryRegions() for Linux and Mac OSX core files.Howard Hellyer2016-07-071-0/+33
| | | | | | | | | | | | | | | Summary: This patch fills in the implementation of GetMemoryRegions() on the Linux and Mac OS core file implementations of lldb_private::Process (ProcessElfCore::GetMemoryRegions and ProcessMachCore::GetMemoryRegions.) The GetMemoryRegions API was added under: http://reviews.llvm.org/D20565 The patch re-uses the m_core_range_infos list that was recently added to implement GetMemoryRegionInfo in both ProcessElfCore and ProcessMachCore to ensure the returned regions match the regions returned by Process::GetMemoryRegionInfo(addr_t load_addr, MemoryRegionInfo &region_info). Reviewers: clayborg Subscribers: labath, lldb-commits Differential Revision: http://reviews.llvm.org/D21751 llvm-svn: 274741
* Process::StopForDetachOrDestroy should actually return an error if it can't ↵Jim Ingham2016-06-281-1/+1
| | | | | | | | | | stop the process. <rdar://problem/26990309> llvm-svn: 274032
* [lldb] Fixed race conditions on private state thread exitCameron Desrochers2016-06-141-26/+28
| | | | | | | | | | This patch fixes various races between the time the private state thread is signaled to exit and the time it actually exits (during which it no longer responds to events). Previously, this was consistently causing 2-second timeout delays on process detach/stop for us. This also prevents crashes that were caused by the thread controlling its own owning pointer while the controller was using it (copying the thread wrapper is not enough to mitigate this, since the internal thread object was getting reset anyway). Again, we were seeing this consistently. Differential Revision: http://reviews.llvm.org/D21296 llvm-svn: 272682
* Now that there are no cycles that cause leaks in the ↵Greg Clayton2016-06-071-6/+0
| | | | | | | | disassembler/instruction classes, we can get rid of the FIXME lines that were working around this issue. <rdar://problem/26684190> llvm-svn: 272071
* Lock out Process::RunThreadPlan so only one can be in flight at a time.Jim Ingham2016-05-241-1/+4
| | | | | | | | | | | | What with all sorts of folks (TSAN, ASAN, queue detection, etc...) trying to gather info by calling functions down in the lower layers of lldb, we've started to see people running expressions simultaneously. The expression evaluation part is okay, but only one RunThreadPlan can be active at a time. I added a lock to enforce that. <rdar://problem/26431072> llvm-svn: 270593
* We have many radars showing that stepping through C++ code can result in ↵Greg Clayton2016-05-231-1/+11
| | | | | | | | | | | | slow steps. One of the things slowing us down is that ItaniumABILanguageRuntime class doesn't cache vtable to types in a map. This causes us, on every step, for every variable, to read the first pointer in a C++ type that could be dynamic and lookup the symbol, possibly in every symbol file (some symbols files on Darwin can end up having thousands of .o files when using DWARF in .o files, so thousands of .o files are searched each time). This fix caches lldb_private::Address (the resolved vtable symbol address in section + offset format) to TypeAndOrName instances inside the one ItaniumABILanguageRuntime in a process. This allows caching of dynamic types and stops us from always doing deep searches in each file. <rdar://problem/18890778> llvm-svn: 270488
* second pass over removal of Mutex and ConditionSaleem Abdulrasool2016-05-191-100/+94
| | | | llvm-svn: 270024
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-181-1/+1
| | | | | | | | | | This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
* Fix some long standing issues that caused tests to be flaky. Greg Clayton2016-05-121-35/+33
| | | | | | | | | | | | | | | | | | The main issues were: - Listeners recently were converted over to used by getting a shared pointer to a listener. And when they listened to broadcasters they would get a strong reference added to them meaning the listeners would never go away. This caused memory usage to increase and would cause performance issue if many steps were done. - The lldb_private::Process private state thread had an issue where if a "stop" contol signal was attempted to be sent to that thread, it could end up not responding in 2 seconds and end up getting cancelled which might cause us to cancel a thread that had a mutex locked and it would deadlock the test. This change makes broadcasters hold onto weak references to listeners. It also fixes some bad threading code that had races inside of it by making the m_events_mutex be non-recursive and getting rid of fragile use of a Predicate<bool> to say that new events are available, and replacing it with using the m_events_mutex with a new m_events_condition to control access to the events in a safer way. The private state thread now uses a safer way to communicate that the control event has been received by the private state thread: it makes a EventDataReceipt instance that it attaches to the event that sends the control to the private state thread and used this to synchronize the fact that the private state thread has received the event instead of using a Predicate<bool> to convey the info. When the signal event is received, it will pull the event off of the queue in the private state thread and cause the EventData::DoOnRemoval() to be called, which will signal that the event has been received. This cleans up the signal delivery notification so it doesn't rely on a member variable of the process class to convey the info. std::shared_ptr<EventDataReceipt> event_receipt_sp(new EventDataReceipt()); m_private_state_control_broadcaster.BroadcastEvent(signal, event_receipt_sp); <rdar://problem/26256353> Listeners are being kept around longer than they should be due to recent changs <rdar://problem/26256258> Private process state thread can be cancelled and cause deadlocks in test suite llvm-svn: 269377
* Generalize child process monitoring functionsPavel Labath2016-05-111-12/+6
| | | | | | | | | | | | | | | | | | | | | | Summary: This replaces the C-style "void *" baton of the child process monitoring functions with a more C++-like API taking a std::function. The motivation for this was that it was very difficult to handle the ownership of the object passed into the callback function -- each caller ended up implementing his own way of doing it, some doing it better than others. With the new API, one can just pass a smart pointer into the callback and all of the lifetime management will be handled automatically. This has enabled me to simplify the rather complicated handshake in Host::RunShellCommand. I have left handling of MonitorDebugServerProcess (my original motivation for this change) to a separate commit to reduce the scope of this change. Reviewers: clayborg, zturner, emaste, krytarowski Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20106 llvm-svn: 269205
* 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
OpenPOWER on IntegriCloud