summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/Windows
Commit message (Collapse)AuthorAgeFilesLines
...
* [Windows] Fix a bug that causes lldb to freezeAaron Smith2018-10-102-5/+15
| | | | | | | | | | | | | | | | | | | | | Summary: If the process exits before any initial stop then notify the debugger of the error otherwise WaitForDebuggerConnection() will be blocked. An example of this issue is when a process fails to load a dependent DLL. In addition to the fix, remove a duplicate call to FreeProcessHandles() in DebuggerThread::HandleExitProcessEvent() and use decimal format for all thread IDs. Reviewers: rnk, zturner, aleksandr.urakov Reviewed By: zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D53090 llvm-svn: 344168
* Replace boolean parameter with enum value according r342633Tatyana Krasnukha2018-09-201-1/+1
| | | | llvm-svn: 342671
* Move Predicate.h from Host to UtilityRaphael Isemann2018-08-302-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This class was initially in Host because its implementation used to be very OS-specific. However, with C++11, it has become a very simple std::condition_variable wrapper, with no host-specific code. It is also a general purpose utility class, so it makes sense for it to live in a place where it can be used by everyone. This has no effect on the layering right now, but it enables me to later move the Listener+Broadcaster+Event combo to a lower layer, which is important, as these are used in a lot of places (notably for launching a process in Host code). Reviewers: jingham, zturner, teemperor Reviewed By: zturner Subscribers: xiaobai, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D50384 llvm-svn: 341089
* Move RegisterValue,Scalar,State from Core to UtilityPavel Labath2018-08-074-4/+4
| | | | | | | | | | | | | These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
* [windows] Fix out-of-memory failure in some of the testsStella Stamenova2018-07-111-22/+40
| | | | | | | | | | | | | | Summary: When ReadProcessMemory fails, bytes_read is sometimes set to a large garbage value. In that case, we need to set it back to zero before returning or the garbage value will be used to allocate memory later causing LLDB to crash with an out of memory error. Reviewers: asmith, zturner Reviewed By: zturner Subscribers: zturner, asmith, stella.stamenova, llvm-commits Differential Revision: https://reviews.llvm.org/D49159 llvm-svn: 336865
* [windows] LLDB shows the wrong values when register read is executed at a ↵Stella Stamenova2018-07-102-29/+42
| | | | | | | | | | | | | | | | | | | frame other than zero Summary: This is a clean version of the change suggested here: https://bugs.llvm.org/show_bug.cgi?id=37495 The main change is to follow the same pattern as non-windows targets and use an unwinder object to retrieve the register context. I also changed a couple of the comments to actually log, so that issues with unsupported scenarios can be tracked down more easily. Lastly, ClearStackFrames is implemented in the base class, so individual thread implementations don't have to override it. Reviewers: asmith, zturner, aleksandr.urakov Reviewed By: aleksandr.urakov Subscribers: emaste, stella.stamenova, tatyana-krasnukha, llvm-commits Differential Revision: https://reviews.llvm.org/D49111 llvm-svn: 336732
* [lldbsuite, windows] Don't crash LLDB when we try to retrieve a register on ↵Stella Stamenova2018-07-022-0/+6
| | | | | | | | | | | | | | | | Windows Summary: 1) When ReadRegister is called with a null register into on Windows, rather than crashing due to an access violation, simply return false. Not all registers and properties will be read or calculated correctly, but that is consistent with other platforms that also return false in that case 2) Update a couple of tests to reference pr37995 as their reason for failure since it is much more accurate. Support for floating point registers doesn't exist on Windows at all, rather than having issues. Reviewers: asmith, labath, zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48844 llvm-svn: 336147
* Use the API's to get the TargetSP.Jim Ingham2018-06-261-1/+1
| | | | llvm-svn: 335690
* [lit] Split test_set_working_dir TestProcessLaunch into two tests and fix it ↵Stella Stamenova2018-06-132-7/+23
| | | | | | | | | | | | | | | | | | | | | | on Windows Summary: test_set_working_dir was testing two scenario: failure to set the working dir because of a non existent directory and succeeding to set the working directory. Since the negative case fails on both Linux and Windows, the positive case was never tested. I split the test into two which allows us to always run both the negative and positive cases. The positive case now succeeds on Linux and the negative case still fails. During the investigation, it turned out that lldbtest.py will try to execute a process launch command up to 3 times if the command failed. This means that we could be covering up intermittent failures by running any test that does process launch multiple times without ever realizing it. I've changed the counter to 1 (though it can still be overwritten with the environment variable). This change also fixes both the positive and negative cases on Windows. There were a few issues: 1) In ProcessLauncherWindows::LaunchProcess, the error was not retrieved until CloseHandle was possibly called. Since CloseHandle is also a system API, its success would overwrite any existing error that could be retrieved using GetLastError. So by the time the error was retrieved, it was now a success. 2) In DebuggerThread::StopDebugging TerminateProcess was called on the process handle regardless of whether it was a valid handle. This was causing the process to crash when the handle was LLDB_INVALID_PROCESS (0xFFFFFFFF). 3) In ProcessWindows::DoLaunch we need to check that the working directory exists before launching the process to have the same behavior as other platforms which first check the directory and then launch process. This way we also control the exact error string. Reviewers: labath, zturner, asmith, jingham Reviewed By: labath Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48050 llvm-svn: 334642
* [lldb, process] Fix occasional hang when launching a process in LLDBStella Stamenova2018-06-011-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Occasionally, when launching a process in lldb (especially on windows, but not limited to), lldb will hang before the process is launched and it will never recover. This happens because the timing of the processing of the state changes can be slightly different. The state changes that are issued are: 1) SetPublicState(eStateLaunching) 2) SetPrivateState(eStateLaunching) 3) SetPublicState(eStateStopped) 4) SetPrivateState(eStateStopped) What we expect to see is: public state: launching -> launching -> stopped private state: launching -> stopped What we see is: public state: launching -> stopped -> launching private state: launching -> stopped The second launching change to the public state is issued when WaitForProcessStopPrivate calls HandlePrivateEvent on the event which was created when the private state was set to launching. HandlePrivateEvent has logic to determine whether to broadcase the event and a launching event is *always* broadcast. At the same time, when the stopped event is processed by WaitForProcessStopPrivate next, the function exists and that event is never broadcast, so the public state remains as launching. HandlePrivateEvent does two things: determine whether there's a next action as well as determine whether to broadcast the event that was processed. There's only ever a next action set if we are trying to attach to a process, but WaitForProcessStopPrivate is only ever called when we are launching a process or connecting remotely, so the first part of HandlePrivateEvent (handling the next action) is irrelevant for WaitForProcessStopPrivate. As far as broadcasting the event is concerned, since we are handling state changes that already occurred to the public state (and are now duplicated in the private state), I believe the broadcast step is unnecessary also (and in fact, it causes the hang). This change removes the call to HandlePrivateEvent from inside WaitForProcessStopPrivate. Incidentally, there was also a bug filed recently that is the same issue: https://bugs.llvm.org/show_bug.cgi?id=37496 Reviewers: asmith, labath, zturner, jingham Reviewed By: zturner, jingham Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47609 llvm-svn: 333781
* Normalize some lldb #include statements.James Y Knight2018-05-224-8/+5
| | | | | | | | | | | Most non-local includes of header files living under lldb/sources/ were specified with the full path starting after sources/. However, in a few instances, other sub-directories were added to include paths, or Normalize those few instances to follow the style used by the rest of the codebase, to make it easier to understand. llvm-svn: 333035
* [Windows, Process] LLDB reads wrong registers on 64bit WindowsStella Stamenova2018-05-171-16/+16
| | | | | | | | | | | | | | | | | | Summary: LLDB reads wrong registers on 64bit Windows because RegisterContextWindows_x64::GetRegisterInfoAtIndex returns wrong reference. I encountered broken backtrace when the program stopped at function which does not have prologue code, such as compiled with '-fomit-frame-pointer'. In this situation, CFA is equal to rsp but LLDB reads r9. RegisterContextWindows_x64::GetRegisterInfoAtIndex depends the order of lldb_XXX_x86_64 values, but RegisterIndex/g_register_infos/g_gpr_reg_indices does not follow order. In source/Plugins/Process/Utility/lldb-x86-register-enums.h The order of GPRs is rax, rbx, rcx, rdx, rdi, rsi, rbp, rsp, r8, ... In source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp The order of GPRs is rax, rbx, rcx, rdx, rdi, rsi, r8, r9, r10, ... Patch by Kenji Koyanagi llvm-svn: 332671
* [Windows, Process] Fix an issue in windows thread handling that was causing ↵Stella Stamenova2018-05-173-7/+25
| | | | | | | | | | | | | | | | LLDB to hang Summary: The function ResumeThread on Windows returns a DWORD which is an unsigned int. In TargetThreadWindows::DoResume, there's code that determines how many times to call ResumeThread based on whether the return value is greater than 0. Since the function returns -1 (as an unsigned int) on failure, this was getting stuck in an infinite loop if ResumeThread failed for any reason. The correct thing to do is check whether the return value is -1 and then return the appropriate error instead of ignoring the return value. Reviewers: asmith, zturner, labath Reviewed By: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47020 llvm-svn: 332670
* Fix Windows build for the Predicate.h refactor in r331880Pavel Labath2018-05-091-2/+2
| | | | llvm-svn: 331882
* Reflow paragraphs in comments.Adrian Prantl2018-04-304-116/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
* Rename Error -> Status.Zachary Turner2017-05-1210-77/+78
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* iwyu fixes for lldbCore.Zachary Turner2017-04-062-0/+2
| | | | | | | | | | | | | | This adjusts header file includes for headers and source files in Core. In doing so, one dependency cycle is eliminated because all the includes from Core to that project were dead includes anyway. In places where some files in other projects were only compiling due to a transitive include from another header, fixups have been made so that those files also include the header they need. Tested on Windows and Linux, and plan to address failures on OSX and FreeBSD after watching the bots. llvm-svn: 299714
* Move FileSpec from Host -> Utility.Zachary Turner2017-03-221-1/+1
| | | | llvm-svn: 298536
* Fix windows&darwin builds broken by r297812Pavel Labath2017-03-151-1/+0
| | | | llvm-svn: 297819
* Delete LLDB's code for getting / setting thread name.Zachary Turner2017-03-041-2/+2
| | | | | | | This is now functionality in LLVM, and all callers have already been updated to use the LLVM functions. llvm-svn: 296946
* Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner2017-03-041-1/+1
| | | | llvm-svn: 296943
* Move Log from Core -> Utility.Zachary Turner2017-03-033-4/+4
| | | | | | | | | All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
* Switch "windows" log channel to the new registration mechanismPavel Labath2017-02-232-159/+17
| | | | llvm-svn: 295968
* Replace WINLOG_*** macros with LLDB_LOGPavel Labath2017-02-226-374/+244
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The main difference here is that in the WINLOG macros you can specify log categories per call, whereas here you have to go the usual lldb route of getting a Log* variable first. While this means you have to write at least two statements, it usually means that each statement will fit on a single line, whereas fitting the WINLOG invocation on a single line was almost impossible. So the total size of code does not increase even in functions with a single log statement, and functions with more logging get shorter. The downside here is reduced flexibility in specifying the log categories, which a couple of functions used quite heavily (e.g. RefreshStateAfterStop). For these I chose a single category used most prominently and put everything into that, although a solution with multiple log variables is definitely possible. Reviewers: zturner, amccarth Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D30172 llvm-svn: 295822
* Try to fix windows build (broken by r294939)Pavel Labath2017-02-132-6/+2
| | | | | | log->Debug is gone, switch to using log->Verbose llvm-svn: 294944
* Really fix windows buildPavel Labath2017-02-101-2/+2
| | | | | | this time I have actually tried that it compiles on windows. llvm-svn: 294744
* Fix darwin and windows builds broken by r294736Pavel Labath2017-02-102-5/+7
| | | | | | Update the platform-specific log classes to match the new interface. llvm-svn: 294743
* [CMake] Final dependency cleanup patch!Chris Bieneman2017-02-081-0/+2
| | | | | | | | | | | | | | | | | Summary: This patch removes the over-specified dependencies from LLDBDependencies and instead relies on the dependencies as expressed in each library and tool. This also removes the library looping in favor of allowing CMake to do its thing. I've tested this patch on Darwin, and found no issues, but since linker semantics vary by system I'll also work on testing it on other platforms too. Help testing would be greatly appreciated. Reviewers: labath, zturner Subscribers: danalbert, srhines, mgorny, jgosnell, lldb-commits Differential Revision: https://reviews.llvm.org/D29352 llvm-svn: 294515
* Switch std::call_once to llvm::call_onceKamil Rytarowski2017-02-062-4/+6
| | | | | | | | | | | | | | | | | | | | | Summary: The std::call_once implementation in libstdc++ has problems on few systems: NetBSD, OpenBSD and Linux PPC. LLVM ships with a homegrown implementation llvm::call_once to help on these platforms. This change is required in the NetBSD LLDB port. std::call_once with libstdc++ results with crashing the debugger. Sponsored by <The NetBSD Foundation> Reviewers: labath, joerg, emaste, mehdi_amini, clayborg Reviewed By: labath, clayborg Subscribers: #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D29288 llvm-svn: 294202
* Move classes from Core -> Utility.Zachary Turner2017-02-025-5/+5
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* [CMake] [3/4] Update a batch of pluginsChris Bieneman2017-01-311-1/+9
| | | | | | This is extending the updates from r293696 to more LLDB plugins. llvm-svn: 293700
* Fix build for mingw.Hafiz Abid Qadeer2016-12-151-1/+1
| | | | | | | | | | | | Summary: I was building lldb using cross mingw-w64 toolchain on Linux and observed some issues. This is first patch in the series to fix that build. It mostly corrects the case of include files and adjusts some #ifdefs from _MSC_VER to _WIN32 and vice versa. I built lldb on windows with VS after applying this patch to make sure it does not break the build there. Reviewers: zturner, labath, abidh Subscribers: ki.stfu, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D27759 llvm-svn: 289821
* Fix a typo.Hafiz Abid Qadeer2016-11-291-1/+1
| | | | llvm-svn: 288118
* [lldb] Fix typos in file headersAlexander Shaposhnikov2016-11-261-2/+1
| | | | | | | | | | | | | This diff fixes typos in file headers (incorrect file names). Test plan: Under llvm/tools/lldb/source: find ./* -type f | grep -e '\(cpp\|h\)$' | while read F; do B=$(basename $F); echo $F head -n 1 $F | grep -v $B | wc -l ; done Differential revision: https://reviews.llvm.org/D27115 llvm-svn: 287966
* Refactor LLDB's Windows process plugin (NFC)Adrian McCarthy2016-11-2322-1760/+1228
| | | | | | | | | | | | | | | | | | | | The Windows process plugin was broken up into multiple pieces a while back in order to share code between debugging live processes and minidumps (postmortem) debugging. The minidump portion was replaced by a cross-platform solution. This left the plugin split into a formerly "common" base classes and the derived classes for live debugging. This extra layer made the code harder to understand and work with. This patch simplifies these class hierarchies by rolling the live debugging concrete classes up to the base classes. Last week I posted my intent to make this change to lldb-dev, and I didn't hear any objections. This involved moving code and changing references to classes like ProcessWindowsLive to ProcessWindows. It still builds for both 32- and 64-bit, and the tests still pass on 32-bit. (Tests on 64-bit weren't passing before this refactor for unrelated reasons.) llvm-svn: 287770
* Remove Windows-specific minidump pluginAdrian McCarthy2016-11-169-1025/+0
| | | | | | | | | | | | With the cross-platform minidump plugin working, the Windows-specific one is no longer needed. This eliminates the unnecessary code. This does not eliminate the Windows-specific tests, as they hit a few cases the general tests don't. (The Windows-specific tests are currently passing.) I'll look into a separate patch to make sure we're not doing too much duplicate testing. After that I might do a little re-org in the Windows plugin, as there was some factoring there (Common & Live) that probably isn't necessary anymore. Differential Revision: https://reviews.llvm.org/D26697 llvm-svn: 287113
* Revert unwanted changes in lldb when updating llvm::Error()Mehdi Amini2016-11-112-3/+3
| | | | | | | | My script updated lldb::Errors, and I failed to fix it entirely before pushing. This restore everything in lldb as it was before r286561. llvm-svn: 286565
* Make the Error class constructor protectedMehdi Amini2016-11-112-3/+3
| | | | | | | | | This is forcing to use Error::success(), which is in a wide majority of cases a lot more readable. Differential Revision: https://reviews.llvm.org/D26481 llvm-svn: 286561
* Make lldb -Werror clean on Windows.Zachary Turner2016-10-057-112/+128
| | | | | | Differential Revision: https://reviews.llvm.org/D25247 llvm-svn: 283344
* Add namespace qualifiers for UTF functions that just moved.Adrian McCarthy2016-09-301-5/+5
| | | | llvm-svn: 282871
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-0636-3680/+3427
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Implement GetMemoryRegions() for Windows Minidumps and live processes.Howard Hellyer2016-07-182-14/+80
| | | | | | | | | | | | | | | | | Summary: This patch fills in the implementation of GetMemoryRegions() on the Windows live process and minidump implementations of lldb_private::Process (ProcessWindowsLive::GetMemoryRegionInfo and ProcessWinMiniDump::Impl::GetMemoryRegionInfo.) The GetMemoryRegions API was added under: http://reviews.llvm.org/D20565 The existing Windows implementations didn’t fill in the start and end addresses within MemoryRegionInfo. This patch fixes that and adds support for the new mapped flag on MemoryRegionInfo that says whether a memory range is mapped into the process address space or not. The behaviour of both live and core implementations should match the behaviour documented on Process::GetMemoryRegionInfo (in Process.h) which in turn should match the behaviour of the qMemoryRegionInfo query documented in lldb-gdb-remote.txt. Reviewers: clayborg, amccarth Subscribers: amccarth, lldb-commits Differential Revision: https://reviews.llvm.org/D22352 llvm-svn: 275778
* (Minor tweak) Make RegisterContextWindows_x86/x64::GetRegisterInfoAtIndex Carlo Kok2016-06-062-2/+9
| | | | | | | | | | | | return NULL for an invalid register. The unwind logic asks for the "return address register" which doesn't exist on x86/x86_64, returns -1 and calls this with -1 as a parameter, ends up out of scope of the array bounds for g_register_infos and later SIGSEGVs on accessing. This now matches the other GetRegisterInfoAtIndex for other platforms. llvm-svn: 271876
* Generalize child process monitoring functionsPavel Labath2016-05-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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
* Update for llvm change to add pdb namespace.Zachary Turner2016-05-041-1/+1
| | | | | | | r268544 moves all PDB reading code into a pdb namespace, so LLDB needs to be updated to take this into account. llvm-svn: 268545
* Set the architecture type from minidump more precisely. Differentiate i686 ↵Adrian McCarthy2016-04-041-2/+10
| | | | | | v i386 when possible. llvm-svn: 265308
* Unicode support on Win32.Zachary Turner2016-03-223-10/+23
| | | | | | | | | | | | | Win32 API calls that are Unicode aware require wide character strings, but LLDB uses UTF8 everywhere. This patch does conversions wherever necessary when passing strings into and out of Win32 API calls. Patch by Cameron Differential Revision: http://reviews.llvm.org/D17107 Reviewed By: zturner, amccarth llvm-svn: 264074
* Try to fix windows build after rL262863Tamas Berghammer2016-03-081-1/+1
| | | | llvm-svn: 262923
* Change over the broadcaster/listener process to hold shared or weak pointersJim Ingham2016-03-076-14/+14
| | | | | | | | | | | | | | 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
* NFC: Refactor ProcessWinMiniDump to use a more traditional pimpl idiom.Adrian McCarthy2016-02-292-274/+309
| | | | | | | | This is a mechanical refactor. There should be no functional changes in this commit. Instead of encapsulating just the Windows-specific data, ProcessWinMiniDump now uses a private implementation class. This reduces indirections (in the source). It makes it easier to add private helper methods without touching the header and allows them to have platform-specific types as parameters. The only trick was that the pimpl class needed a back pointer in order to call a couple methods. llvm-svn: 262256
OpenPOWER on IntegriCloud