summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix Clang-tidy modernize-use-override warnings in some files in ↵Eugene Zelenko2015-10-199-137/+168
| | | | | | | | source/Plugins; other minor fixes. Differential Revision: http://reviews.llvm.org/D13840 llvm-svn: 250721
* Fix for random watchpoint testsuite failures on AArch64 targets.Omair Javaid2015-10-191-1/+4
| | | | | | | | This patch corrects the number of bytes of debug register resources which are written while installing or removing a breakpoint using ptrace interface on arm64 targets. Differential revision: http://reviews.llvm.org/D12522 llvm-svn: 250700
* [LLDB][MIPS] Use the correct ptrace buffer for writing register value for ↵Sagar Thakur2015-10-191-8/+9
| | | | | | | | | o32 applications For o32 applications on mips we were getting segmentation fault while launching lldb-server because of overwritting stack when using elf_gregset_t in DoWriteRegisterValue. We are now using the GPR_mips_linux buffer in DoWriteRegisterValue as done in DoReadRegisterValue also, which solves the above issue. llvm-svn: 250696
* Silence -Wqual-cast warnings from GCC 5.2Saleem Abdulrasool2015-10-181-1/+2
| | | | | | | | There were a number of const qualifiers being cast away which caused warnings. This cluttered the output hiding real errors. Silence them by explicit casting. NFC. llvm-svn: 250662
* [LLDB] Fix Clang-tidy modernize-use-override warnings in some headers in ↵Eugene Zelenko2015-10-1717-367/+375
| | | | | | | | source/Plugins/Process/Utility; other minor fixes. Differential Revision: http://reviews.llvm.org/D13830 llvm-svn: 250593
* Split Socket class into Tcp/Udp/DomainSocket subclasses.Oleksiy Vyalov2015-10-151-2/+2
| | | | | | http://reviews.llvm.org/D13754 llvm-svn: 250474
* In r240466, when Greg added the jThreadsInfo packet, he accidentallyJason Molenda2015-10-151-1/+0
| | | | | | | | | | | | | | disabled the use of the jThreadGetExtendedInfo packet which is used to retrieve additional information about a thread, such as the QoS setting for that thread on darwin systems. Re-enable the use of the jThreadGetExtendedInfo packet, and add some quick tests to the TestQueues mac test case which will verify that we can retrieve the QoS names for these test threads. <rdar://problem/22925096> llvm-svn: 250364
* Make uses of /dev/null portable across OSes.Zachary Turner2015-10-141-3/+4
| | | | | | | | | 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
* lldb-server: add support for binary memory readsPavel Labath2015-10-143-14/+19
| | | | | | | | | | | | | | | | | Summary: This commit adds support for binary memory reads ($x) to lldb-server. It also removes the "0x" prefix from the $x client packet, to make it more compatible with the old $m packet. This allows us to use almost the same code for handling both packet types. I have verified that debugserver correctly handles $x packets even without the leading "0x". I have added a test which verifies that the stub returns the same memory contents for both kinds of memory reads ($x and $m). Reviewers: tberghammer, jasonmolenda Subscribers: iancottrell, lldb-commits Differential Revision: http://reviews.llvm.org/D13695 llvm-svn: 250295
* [LLDB] Adding mips32 in the list of archs with ↵Mohit K. Bhakkad2015-10-141-1/+3
| | | | | | watchpoint_exceptions_received=before llvm-svn: 250272
* Fix cast in arm watchpoint handling codeTamas Berghammer2015-10-131-1/+1
| | | | | | | We had an incorrect sign extension when castion from a pointer to an lldb::addr_t what broke the watchpoint hit detection on arm. llvm-svn: 250180
* Fix a misunderstanding of the ThreadPlan::OkayToDiscard flag in ↵Jim Ingham2015-10-121-9/+0
| | | | | | | | | | | | | 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
* X86: Change FTAG register size in FXSAVE structureAbhishek Aggarwal2015-10-124-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - Changed from 16 bits to 8 bits for Intel Architecture -- FXSAVE structure now conforms with the layout of FXSAVE area specified by IA Architecture Software Developer Manual - Modified Linux and FreeBSD specific files to support this change -- MacOSX already uses 8 bits for ftag register - Modified TestRegisters.py and a.cpp: -- Change allows 8 bit comparison of ftag values -- Change resolves Bug 24733: Removed XFAIL for Clang as the test works and passes for Clang compiler as well -- Change provides a Generic/Better way of testing Bug 24457 and Bug 25050 by using 'int3' inline assembly in inferior Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com> Reviewers: ovyalov, jingham, clayborg Subscribers: tfiala, emaste Differential Revision: http://reviews.llvm.org/D13587 llvm-svn: 250022
* Remove long-forgotten plugin virtuals.Bruce Mitchener2015-10-092-28/+0
| | | | | | | | | | | | | | | Summary: EnablePluginLogging, GetPluginCommandHelp and ExecutePluginCommand aren't implemented or used anywhere, so remove them from the Hexagon and POSIX Dynamic Loaders as well as the FreeBSD process. Reviewers: clayborg, labath, emaste Subscribers: lldb-commits, emaste Differential Revision: http://reviews.llvm.org/D13581 llvm-svn: 249840
* [LLDB][MIPS] fix watchpoint searched on client side for same masked variablesMohit K. Bhakkad2015-10-091-0/+2
| | | | | | | | Reviewers: clayborg, jingham. Subscribers: jaydeep, bhushan, sagar, nitesh.jain, brucem,lldb-commits. Differential Revision: http://reviews.llvm.org/D13548 llvm-svn: 249837
* Re-commit the (fixed) changes from r248985 which were reverted by PavelJason Molenda2015-10-081-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
* Bug 25050: X87 FPU Special Purpose RegistersAbhishek Aggarwal2015-10-062-4/+22
| | | | | | | | | | | | | | | | | Summary: - For x86_64-FreeBSD Platform: -- LLDB now provides correct values of X87 FPU Special Purpose Registers like fstat, ftag, fctrl etc.. Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com> Reviewers: emaste, mikesart, clayborg Subscribers: emaste Differential Revision: http://reviews.llvm.org/D13434 llvm-svn: 249379
* Have a clean(er) shutdown when detaching from a process.Zachary Turner2015-10-021-20/+19
| | | | llvm-svn: 249206
* Fix several issues around .ARM.exidx section handlingTamas Berghammer2015-10-021-10/+10
| | | | | | | | | | | | | | * Use .ARM.exidx as a fallback unwind plan for non-call site when the instruction emulation based unwind failed. * Work around an old compiler issue where the compiler isn't sort the entries in .ARM.exidx based on their address. * Fix unwind info parsing when the virtual file address >= 0x80000000 * Fix bug in unwind info parsing when neither lr nor pc is explicitly restored. Differential revision: http://reviews.llvm.org/D13380 llvm-svn: 249119
* [LLDB][MIPS] Fix gp register value for o32 applications on 64-bit targetSagar Thakur2015-10-011-8/+1
| | | | | | | GP registers for o32 applications were always giving zero value because SetType() on the RegisterValue was causing the accessor functions to pickup the value from m_scalar of RegisterValue which is zero. In this patch byte size and byte order of register value is set at the time of setting the value of the register. llvm-svn: 249020
* Revert "Fixing a subtle issue on Mac OS X systems with dSYMs..."Pavel Labath2015-10-011-7/+1
| | | | | | | This reverts commit r248985, as it was breaking all remote expression-evaluating tests (on android at least). llvm-svn: 248995
* Fixing a subtle issue on Mac OS X systems with dSYMs (possiblyJason Molenda2015-10-011-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 248985
* Removed an unused member variable. Affects Windows only.Adrian McCarthy2015-09-301-2/+0
| | | | llvm-svn: 248909
* Add support for .ARM.exidx unwind informationTamas Berghammer2015-09-301-8/+23
| | | | | | | | | .ARM.exidx/.ARM.extab sections contain unwind information used on ARM architecture from unwinding from an exception. Differential revision: http://reviews.llvm.org/D13245 llvm-svn: 248903
* A small fixup needed for debugserver to work nativelyJason Molenda2015-09-221-61/+64
| | | | | | | | | | | | | | | | | on iOS devices; fallout from Vince's cleanups made in r237218 back in May. iOS native lldbs will call StartDebugserverProcess() with a random port # (see ProcessGDBRemote::LaunchAndConnectToDebugserver) and neither side of this conditional expression should be followed in that case. I added an "if (in_port == 0) { ..." check around the entire if/then/else and indented the block of code so the diff looks larger than it really is. <rdar://problem/21712643> llvm-svn: 248343
* [LLDB][MIPS] Debug bare-iron targets lacking support for qC /qfThreadInfoJaydeep Patil2015-09-181-0/+33
| | | | | | | | | | | SUMMARY: Using response.IsUnsupportedResponse instead of !response.IsNormalResponse(). Reviewers: clayborg, labath Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits Differential Revision: http://reviews.llvm.org/D12876 llvm-svn: 247968
* Get the process ID from a minidump.Adrian McCarthy2015-09-172-2/+23
| | | | llvm-svn: 247939
* Fix a race condition when terminating inferiors on Windows.Zachary Turner2015-09-172-0/+16
| | | | | | | | | | | | | If a breakpoint was hit in the inferior after shutdown had started but before it was complete, it would cause an unclean terminate of the inferior, leading to various problems the most visible of which is that handles to the inferior executable would remain locked, and the test suite would fail to run subsequent tests because it could not recompile the inferior. This fixes a major source of flakiness in the test suite. llvm-svn: 247929
* Fix LLDB RSP client to decode '$O' packets incorrectlyDawn Perchik2015-09-171-3/+7
| | | | | | | | | | | | Character with ASCII code 0 is incorrectly treated by LLDB as the end of RSP packet. The left of the debugger server output is silently ignored. Patch from evgeny.leviant@gmail.com Reviewed by: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12523 llvm-svn: 247908
* Add an OperatingSystem plugin to support goroutinesRyan Brown2015-09-161-0/+4
| | | | | | | | | | 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
* Fix log disable command in ProcessWindowsLog.Zachary Turner2015-09-161-12/+18
| | | | | | | | | | | The implications of this bug where that "log disable windows" would not actually disable the log, and worse it would lock the file handle making it impossible to delete the file until lldb was shut down. This was then causing the test suite to fail, because the test suite tries to delete log files in certain situations. llvm-svn: 247841
* Revert "[LLDB][MIPS] Debug bare-iron targets lacking support for qC ↵Pavel Labath2015-09-161-33/+0
| | | | | | | | /qfThreadInfo" This reverts commit r247773, because it breaks remote debugging support for lldb-server. llvm-svn: 247783
* [LLDB][MIPS] Debug bare-iron targets lacking support for qC /qfThreadInfoJaydeep Patil2015-09-161-0/+33
| | | | | | | | | | | | | | SUMMARY: Refer to http://lists.llvm.org/pipermail/lldb-dev/2015-August/008024.html for discussion on this topic. Bare-iron target like YAMON gdb-stub does not support qProcessInfo, qC, qfThreadInfo, Hg and Hc packets. Reply from ? packet is as simple as S05. There is no packet which gives us process or threads information. In such cases, assume pid=tid=1. Reviewers: clayborg Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits Differential Revision: http://reviews.llvm.org/D12876 llvm-svn: 247773
* Clean up register naming conventions inside lldb. Jason Molenda2015-09-1525-2140/+1413
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "gcc" register numbers are now correctly referred to as "ehframe" register numbers. In almost all cases, ehframe and dwarf register numbers are identical (the one exception is i386 darwin where ehframe regnums were incorrect). The old "gdb" register numbers, which I incorrectly thought were stabs register numbers, are now referred to as "Process Plugin" register numbers. This is the register numbering scheme that the remote process controller stub (lldb-server, gdbserver, core file support, kdp server, remote jtag devices, etc) uses to refer to the registers. The process plugin register numbers may not be contiguous - there are remote jtag devices that have gaps in their register numbering schemes. I removed all of the enums for "gdb" register numbers that we had in lldb - these were meaningless - and I put LLDB_INVALID_REGNUM in all of the register tables for the Process Plugin regnum slot. This change is almost entirely mechnical; the one actual change in here is to ProcessGDBRemote.cpp's ParseRegisters() which parses the qXfer:features:read:target.xml response. As it parses register definitions from the xml, it will assign sequential numbers as the eRegisterKindLLDB numbers (the lldb register numberings must be sequential, without any gaps) and if the xml file specifies register numbers, those will be used as the eRegisterKindProcessPlugin register numbers (and those may have gaps). A J-Link jtag device's target.xml does contain a gap in register numbers, and it only specifies the register numbers for the registers after that gap. The device supports many different ARM boards and probably selects different part of its register file as appropriate. http://reviews.llvm.org/D12791 <rdar://problem/22623262> llvm-svn: 247741
* Use SI_KERNEL on platforms defining itStephane Sezer2015-09-141-2/+3
| | | | | | | | | | | | | | | | | Summary: Linux and FreeBSD occasionally send SI_KERNEL codes, nonexistent on other platforms. Problem caught on NetBSD. Reviewers: joerg, sas Subscribers: sas, lldb-commits, emaste Differential Revision: http://reviews.llvm.org/D12659 Change by Kamil Rytarowski <n54@gmx.com> llvm-svn: 247579
* Move RegisterContextPOSIX.h to FreeBSD subdirEd Maste2015-09-142-1/+1
| | | | | | It is now used only by the FreeBSD in-process ptrace implementation. llvm-svn: 247561
* Limit scope of RegisterContextPOSIX.h headerEd Maste2015-09-1425-21/+23
| | | | | | | | | | | | | | | RegisterContextPOSIX.h is poorly named and contains only the declaration of POSIXBreakpointProtocol, which is used for in-process live kernel debugging. It is now relevant only to FreeBSD. In source/Plugins/Process/Utility/RegisterContext*.h (after assorted rework and refactoring) it only served the purpose of #including other necessary headers as a side-effect. Remove it from them and just include the required headers directly. Differential Revision: http://reviews.llvm.org/D12830 llvm-svn: 247558
* Switch default disposition of realtime signalsPavel Labath2015-09-143-130/+130
| | | | | | | | | | | | | | | | | | | | | Summary: Realtime signals generally do not represent an error condition in an application but are more like a regular means of IPC. As such, we shouldn't interrupt an application whenever it recieves one. If any application will use these signals, it will probably use them a lot, rendering it's debugging tiresome if we stopped at every signal. Furthermore, these signals are likely to be used in a low level library, and the programmer may not even be aware of their presence. For these reasons, I am switching the default disposition of realtime signals on all supported platforms (i.e. Linux and Freebsd) to no-stop, no-notify. Any user still wishing to receive these signals can always change the default to suit his needs. Reviewers: ovyalov, emaste Subscribers: lldb-commits, emaste Differential Revision: http://reviews.llvm.org/D12795 llvm-svn: 247537
* Fix a small comment typo in Windows Process code.Stephane Sezer2015-09-091-3/+3
| | | | llvm-svn: 247206
* Change the looping stack detection codeTamas Berghammer2015-09-091-14/+16
| | | | | | | | | | | In some special case (e.g. signal handlers, hand written assembly) it is valid to have 2 stack frame with the same CFA value. This CL change the looping stack detection code to report a loop only if at least 3 consecutive frames have the same CFA. Differential revision: http://reviews.llvm.org/D12699 llvm-svn: 247133
* When lldb gets the register definitions from the response of aJason Molenda2015-09-091-4/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qXfer:features:read:target.xml packet, or via the plugin.process.gdb-remote.target-definition-file setting, if the register definition doesn't give us eh_frame or DWARF register numbers for that register, try to get that information from the ABI plugin. The DWARF/eh_frame register numbers are defined in the ABI standardization documents - so getting this from the ABI plugin is reasonable. There's little value in having the remote stub inform us of this generic information, as long as we can all agree on the names of the registers. There's some additional information we could get from the ABI. For instance, on ABIs where function arguments are passed in registers, lldb defines alternate names like "arg1", "arg2", "arg3" for these registers so they can be referred to that way by the user. We could get this from the ABI if the remote stub doesn't provide that. That may be something worth doing in the future - but for now, I'm keeping this a little more minimal. Thinking about this, what we want/need from the remote stub at a minimum are: 1. The names of the register 2. The number that the stub will use to refer to the register with the p/P packets and in the ? response packets (T/S) where expedited register values are provided 3. The size of the register in bytes (nice to have, to remove any doubt) 4. The offset of the register in the g/G packet if we're going to use that for reading/writing registers. debugserver traditionally provides a lot more information in addition to this via the qRegisterInfo packet, and debugserver augments its response to the qXfer:features:read:target.xml query to include this information. Including: DWARF regnum, eh_frame regnum, stabs regnum, encoding (ieee754, Uint, Vector, Sint), format (hex, unsigned, pointer, vectorof*, float), registers that should be marked as invalid if this register is modified, and registers that contain this register. We might want to get all of this from the ABI - I'm not convinced that it makes sense for the remote stub to provide any of these details, as long as the ABI and remote stub can agree on register names. Anyway, start with eh_frame and DWARF coming from the ABI if they're not provided by the remote stub. We can look at doing more in the future. <rdar://problem/22566585> llvm-svn: 247121
* A change I'm open to reverting if there is disagreement:Jason Molenda2015-09-091-1/+3
| | | | | | | | | | | | | | | | | | | When lldb receives a gdb-remote protocol packet that has nonprintable characters, it will print the packet in gdb-remote logging with binary-hex encoding so we don't dump random 8-bit characters into the packet log. I'm changing this check to allow whitespace characters (newlines, linefeeds, tabs) to be printed if those are the only non-printable characters in the packet. This is primarily to get the response to the qXfer:features:read:target.xml packet to show up in the packet logs in human readable form. Right now we just get a dozen kilobytes of hex-ascii and it's hard to figure out what register number scheme is being used. llvm-svn: 247120
* Fix the handling of FPR offsets in Linux arm/aarch64 register contextsTamas Berghammer2015-09-075-9/+32
| | | | | | Differential revision: http://reviews.llvm.org/D12636 llvm-svn: 246959
* Bug 24457 - X87 FPU Special Purpose RegistersAbhishek Aggarwal2015-09-072-4/+25
| | | | | | | | | | | | | | | | | | | | Summary: - For 'register read --all' command on x86_64-Linux Platform: -- Provide correct values of X87 FPU Special Purpose Registers -- Both 32-bit & 64-bit inferiors give correct values on this Platform - Added a Test Vector: -- To verify the expected behaviour of the command Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com> Reviewers: ashok.thirumurthi, granata.enrico, tfiala, clayborg Differential Revision: http://reviews.llvm.org/D12592 llvm-svn: 246955
* Fix deadlock while attaching to inferiorsPavel Labath2015-09-032-148/+159
| | | | | | | | | | | | | | | | | | | | Summary: There was a race condition in the AsyncThread, where we would end up sending a vAttach notification to the thread before it got a chance set up its listener (this can be reproduced by adding a sleep() at the very beginning of ProcessGDBRemote::AsyncThread()). This event would then get lost and we LLDB would deadlock. I fix this by setting up the listener early on, in the ProcessGDBRemote constructor. This should improve the stability of all attach tests. For now, I am removing XTIMEOUT from TestAttachResume, and will watch the buildbots for signs of trouble. Reviewers: clayborg, ovyalov Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12552 llvm-svn: 246756
* [cmake] Remove LLVM_NO_RTTI.Bruce Mitchener2015-09-039-19/+1
| | | | | | | | | | | | | | Summary: This doesn't exist in other LLVM projects any longer and doesn't do anything. Reviewers: chaoren, labath Subscribers: emaste, tberghammer, lldb-commits, danalbert Differential Revision: http://reviews.llvm.org/D12586 llvm-svn: 246749
* Try to fix FreeBSD build.Zachary Turner2015-09-022-15/+15
| | | | llvm-svn: 246672
* Fix ProcessKDP.cpp for the change in r246578.Jim Ingham2015-09-012-16/+18
| | | | llvm-svn: 246601
* Make ProcessWindows not create a strong reference to itself.Zachary Turner2015-09-014-12/+55
| | | | llvm-svn: 246579
* Have the Process hold a weak_ptr to the Target.Zachary Turner2015-09-0110-92/+96
| | | | llvm-svn: 246578
OpenPOWER on IntegriCloud