summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process
Commit message (Collapse)AuthorAgeFilesLines
...
* Change the /proc/<pid>/maps to not assert on incorrect inputTamas Berghammer2016-07-111-12/+9
| | | | | | | | | | If LLDB reads some incorrect input form /proc/<pid>/maps then it should report an error instead of assert-ing as we don't want to crash in case of an incorrect maps file. Differential revision: http://reviews.llvm.org/D22211 llvm-svn: 275060
* [LLGS] Work around an adb bug on Android <=MPavel Labath2016-07-071-0/+12
| | | | | | | On android M it can happen that we get a ETXTBSY, when we try to launch the inferior. Sleeping and retrying should help us get more stable results. llvm-svn: 274763
* Implement GetMemoryRegions() for Linux and Mac OSX core files.Howard Hellyer2016-07-074-14/+29
| | | | | | | | | | | | | | | 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
* [LLGS] Log more precise errors during inferior launchPavel Labath2016-07-062-113/+129
| | | | | | | | | | | | | | Summary: We are seeing infrequent failures to launch the inferior process on android. The failing call seems to be execve(). This adds more logging to see the actual error reported by the call. Reviewers: tberghammer Subscribers: tberghammer, lldb-commits, danalbert Differential Revision: http://reviews.llvm.org/D22039 llvm-svn: 274624
* Remove platform plugins from lldb-serverPavel Labath2016-06-294-10/+3
| | | | | | | | | | | | | | | | | | | Summary: This removes the last usage of Platform plugins in lldb-server -- it was used for launching child processes, where it can be trivially replaced by Host::LaunchProces (as lldb-server is always running on the host). Removing platform plugins enables us to remove a lot of other unused code, which was pulled in as a transitive dependency, and it reduces lldb-server size by 4%--9% (depending on build type and architecture). Reviewers: clayborg Subscribers: tberghammer, danalbert, srhines, lldb-commits Differential Revision: http://reviews.llvm.org/D20440 llvm-svn: 274125
* Improve watchpoint error reporting specially for arm/aarch64 targetsOmair Javaid2016-06-272-2/+2
| | | | | | Differential revision: http://reviews.llvm.org/D21164 llvm-svn: 273869
* Allow unaligned byte/word selection watchpoints for arm- linux/android targets.Omair Javaid2016-06-273-3/+45
| | | | | | Differential revision: http://reviews.llvm.org/D21516 llvm-svn: 273863
* Test commit to verify access, fix typo.Howard Hellyer2016-06-231-1/+1
| | | | llvm-svn: 273546
* Revert r273524, it may have been the cause of a linux testbot failureJason Molenda2016-06-233-4/+4
| | | | | | | | for TestNamespaceLookup.py; didn't see anything obviously wrong so I'll need to look at this more closely before re-committing. (passed OK on macOS ;) llvm-svn: 273531
* Do some minor renames of "Mac OS X" to "macOS".Jason Molenda2016-06-233-4/+4
| | | | | | | | | There's uses of "macosx" that will be more tricky to change, like in triples (e.g. "x86_64-apple-macosx10.11") - for now I'm just updating source comments and strings printed for humans. llvm-svn: 273524
* Allow installing watchpoints at less than 8-byte alligned addresses for ↵Omair Javaid2016-06-163-4/+44
| | | | | | | | | | | | AArch64 targets This patch allows LLDB for AArch64 to watch all bytes, words or double words individually on non 8-byte alligned addresses. This patch also adds tests to verify this functionality. Differential revision: http://reviews.llvm.org/D21280 llvm-svn: 272916
* Remove Platform usages from NativeProcessLinuxPavel Labath2016-06-142-145/+33
| | | | | | | | | | | | | | | | Summary: This removes the last usage of the Platform plugin in NPL. It was being used for determining the architecture of the debugged process. I replace the call that went through the Platform plugin with a lower level call on the ObjectFile directly. Reviewers: tberghammer Subscribers: uweigand, nitesh.jain, omjavaid, lldb-commits Differential Revision: http://reviews.llvm.org/D21324 llvm-svn: 272686
* On MacOSX, the threads can appear out of order at times depending on the ↵Greg Clayton2016-06-101-1/+1
| | | | | | | | order in which the kernel returns thread IDs to debugserver. To avoid thread lists changing order between stops, ProcessGDBRemote now makes sure the thread list stays sorted by thread index ID. <rdar://problem/25501013> llvm-svn: 272444
* Fixed an issue in the ProcessMachCore where segments are not always ↵Greg Clayton2016-06-091-13/+42
| | | | | | | | | | | | | | | | | | | | | | contiguous in mach-o core files. We have core files that have segments like: Address Size File off File size ---------- ---------- ---------- ---------- LC_SEGMENT 0x000f6000 0x00001000 0x1d509ee8 0x00001000 --- --- 0 0x00000000 __TEXT LC_SEGMENT 0x0f600000 0x00100000 0x1d50aee8 0x00100000 --- --- 0 0x00000000 __TEXT LC_SEGMENT 0x000f7000 0x00001000 0x1d60aee8 0x00001000 --- --- 0 0x00000000 __TEXT Any if the user executes the following command: (lldb) mem read 0xf6ff0 We would attempt to read 32 bytes from 0xf6ff0 but would only get 16 unless we loop through consecutive memory ranges that are contiguous in the address space, but not in the file data. This fixes the ProcessMachCore::DoReadMemory() to do the right thing. <rdar://problem/19729287> llvm-svn: 272322
* Some core files on MacOSX don't have permissions setup correctly on the ↵Greg Clayton2016-06-091-1/+8
| | | | | | | | LC_SEGMENT load commands. Assume read + execute if the permissions are not set. <rdar://problem/26720522> llvm-svn: 272281
* Since our expression parser needs to locate areas of memory that are not in ↵Greg Clayton2016-06-094-15/+109
| | | | | | | | use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
* Don't remove PIE executables when using svr4 packetsFrancis Ricci2016-06-061-4/+3
| | | | | | | | | | | | | | | Summary: Because PIE executables have an e_type of llvm::ELF::ET_DYN, they are not of type eTypeExecutable, and were being removed when svr4 packets were used. Reviewers: clayborg, ADodds, tfiala, sas Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20990 llvm-svn: 271899
* (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
* Implement ProcessInfo::Dump(), log gdb-remote stub launchTodd Fiala2016-05-311-2/+9
| | | | | | | | | | | | | | | | | | This change implements dumping the executable, triple, args and environment when using ProcessInfo::Dump(). It also tweaks the way Args::Dump() works so that it prints a configurable label rather than argv[{index}]={value}. By default it behaves the same, but if the Dump() method with the additional arg is provided, it can be overridden. The environment variables dumped as part of ProcessInfo::Dump() make use of that. lldb-server has been modified to dump the gdb-remote stub's ProcessInfo before launching if the "gdb-remote process" channel is logged. llvm-svn: 271312
* fix up lldb-server platform on Apple hostsTodd Fiala2016-05-271-0/+3
| | | | | | | | | | | | r259714 introduces the transport method into the URL passed to the gdb-remote stub. On debugserver, this is not supported and prevented debugserver from being launched by lldb-server in platform mode. This change skips the transport method addition from r259714 when on Apple hosts. llvm-svn: 270961
* A better fix of incorrectly used locking in HistoryThread and HistoryUnwind.Kuba Brecka2016-05-222-2/+2
| | | | llvm-svn: 270363
* Revert r270358 ("Fix an incorrectly used locking in HistoryThread and ↵Kuba Brecka2016-05-222-2/+4
| | | | | | HistoryUnwind"). llvm-svn: 270359
* Fix an incorrectly used locking in HistoryThread and HistoryUnwind, where ↵Kuba Brecka2016-05-222-4/+2
| | | | | | unique_lock's release() was called causing the mutex to stay locked. llvm-svn: 270358
* [LLDB][MIPS] Fix Floating point Registers EncodingSagar Thakur2016-05-202-8/+18
| | | | | | | | | | | Patch by Nitesh Jain. Summary: Currently floating point regsiters has eEncodingUint encoding. Hence register write '1.25' will failed. This patch add eEncodingIEEE754 encoding for floating point registers( - ). This patch will fix test_fp_register_write in TestRegisters.py Reviewers: clayborg, sagar Subscribers: mohit.bhakkad, jaydeep, bhushan, sdardis, lldb-commits Differential: D18853 llvm-svn: 270208
* Some changes to prevent searching down the stack for saved registerJason Molenda2016-05-201-10/+29
| | | | | | | | | | | | | | | | | | | | | | | | values for the pc or return address register. On ios with arm64 and a binary that has multiple functions without individual symbol boundaries, we end up with an assembly profile unwind plan that says lr=<same> - that is, the link register contents are unmodified from the caller's value. This gets the unwinder in a loop. When we're off the 0th frame, we never want to look to a caller for a pc or return-address register value. Add checks to ReadGPRValue and ReadRegister to prevent both the pc and ra register values from recursing. If this causes problems with backtraces on android, let me know or back it out and I'll look into it -- but I think these are straightforward and don't expect problems. <rdar://problem/24610365> llvm-svn: 270162
* second pass over removal of Mutex and ConditionSaleem Abdulrasool2016-05-194-37/+39
| | | | llvm-svn: 270024
* Fix error propagation from the Z0 packet in gdb-remote breakpoint setting.Jim Ingham2016-05-191-3/+17
| | | | | | | | | | | | | The error was not getting propagated to the caller, so the higher layers thought the breakpoint was successfully set & resolved. I added a testcase, but it assumes 0x0 is not a valid place to set a breakpoint. On most systems that is true, but if it isn't true of your system, either find another good place and add it to the test, or x-fail the test. <rdar://problem/26345962> llvm-svn: 270014
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-1819-203/+202
| | | | | | | | | | 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
* Remove Mutex from NativeProcessLinuxPavel Labath2016-05-162-20/+1
| | | | | | | | NPL now assumes it is running from a single thread now, so its thread-safety is untested anyway (and if that assumption is broken, we'll have bigger problems (due to ptrace restrictions) than a couple of missing mutexes). llvm-svn: 269640
* Fix a few -Wformat-pedantic warningsSaleem Abdulrasool2016-05-151-1/+1
| | | | | | Clean up some newly introduced -Wformat-pedantic warnings (%p expects a void *). llvm-svn: 269598
* Fix a race in ProcessGDBRemote::MonitorDebugServerProcessPavel Labath2016-05-122-69/+42
| | | | | | | | | | | | | | | | | | | | | | Summary: MonitorDebugServerProcess went to a lot of effort to make sure its asynchronous invocation does not cause any mischief, but it was still not race-free. Specifically, in a quick stop-restart sequence (like the one in TestAddressBreakpoints) the copying of the process shared pointer via target_sp->GetProcessSP() was racing with the resetting of the pointer in DeleteCurrentProcess, as they were both accessing the same shared_ptr object. To avoid this, I simply pass in a weak_ptr to the process when the callback is created. Locking this pointer is race-free as they are two separate object even though they point to the same process instance. This also removes the need for the complicated tap-dance around retrieving the process pointer. Reviewers: clayborg Subscribers: tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D20107 llvm-svn: 269281
* Generalize child process monitoring functionsPavel Labath2016-05-117-49/+27
| | | | | | | | | | | | | | | | | | | | | | 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
* Use absolute module path when possible if sent in svr4 packetsFrancis Ricci2016-04-271-8/+1
| | | | | | | | | | | | | | | | | | | | | Summary: If the remote uses svr4 packets to communicate library info, the LoadUnload tests will fail, as lldb only used the basename for modules, causing problems when two modules have the same basename. Using absolute path as sent by the remote will ensure that lldb locates the module from the correct directory when there are overlapping basenames. When debugging a remote process, LoadModuleAtAddress will still fall back to using basename and module_search_paths, so we don't need to worry about using absolute paths in this case. Reviewers: ADodds, jasonmolenda, clayborg, ovyalov Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19557 llvm-svn: 267741
* Maintain register numbering across xml include featuresFrancis Ricci2016-04-251-6/+7
| | | | | | | | | | | | | | | | | | Summary: If the remote uses include features when communicating xml register info back to lldb, the existing code would reset the lldb register index at the beginning of each include node. This would lead to multiple registers having the same lldb register index. Since the lldb register numbers should be contiguous and unique, maintain them accross the parsing of all of the xml feature nodes. Reviewers: jingham, jasonmolenda, clayborg Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19303 llvm-svn: 267468
* Properly unload modules from target image list when using svr4 packetsFrancis Ricci2016-04-251-2/+24
| | | | | | | | | | | | | | | | | | | Summary: When we receive an svr4 packet from the remote, we check for new modules and add them to the list of images in the target. However, we did not do the same for modules which have been removed. This was causing TestLoadUnload to fail when using ds2, which uses svr4 packets to communicate all library info on Linux. This patch fixes the failing test. Reviewers: zturner, tfiala, ADodds Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19230 llvm-svn: 267467
* Use Process Plugin register indices when communicating with remoteFrancis Ricci2016-04-252-8/+9
| | | | | | | | | | | | | | | | | | Summary: eRegisterKindProcessPlugin is used to store the register indices used by the remote, and eRegisterKindLLDB is used to store the internal lldb register indices. However, we're currently using the lldb indices instead of the process plugin indices when sending p/P packets. This will break if the remote uses non-contiguous register indices. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19305 llvm-svn: 267466
* Fix unwind failures when PC points beyond the end of a functionUlrich Weigand2016-04-241-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RegisterContextLLDB::InitializeNonZerothFrame already has code to attempt to detect and handle the case where the PC points beyond the end of a function, but there are certain cases where this doesn't work correctly. In fact, there are *two* different places where this detection is attempted, and the failure is in fact a result of an unfortunate interaction between those two separate attempts. First, the ResolveSymbolContextForAddress routine is called with the resolve_tail_call_address flag set to true. This causes the routine to internally accept a PC pointing beyond the end of a function, and still resolving the PC to that function symbol. Second, the InitializeNonZerothFrame routine itself maintains a "decr_pc_and_recompute_addr_range" flag and, if that turns out to be true, itself decrements the PC by one and searches again for a symbol at that new PC value. Both approaches correctly identify the symbol associated with the PC. However, the problem is now that later on, we also need to find the DWARF CFI record associated with the PC. This is done in the RegisterContextLLDB::GetFullUnwindPlanForFrame routine, and uses the "m_current_offset_backed_up_one" member variable. However, that variable only actually contains the PC "backed up by one" if the *second* approach above was taken. If the function was already identified via the first approach above, that member variable is *not* backed up by one but simply points to the original PC. This in turn causes GetEHFrameUnwindPlan to not correctly identify the DWARF CFI record associated with the PC. Now, in many cases, if the first method had to back up the PC by one, we *still* use the second method too, because of this piece of code: // Or if we're in the middle of the stack (and not "above" an asynchronous event like sigtramp), // and our "current" pc is the start of a function... if (m_sym_ctx_valid && GetNextFrame()->m_frame_type != eTrapHandlerFrame && GetNextFrame()->m_frame_type != eDebuggerFrame && addr_range.GetBaseAddress().IsValid() && addr_range.GetBaseAddress().GetSection() == m_current_pc.GetSection() && addr_range.GetBaseAddress().GetOffset() == m_current_pc.GetOffset()) { decr_pc_and_recompute_addr_range = true; } In many cases, when the PC is one beyond the end of the current function, it will indeed then be exactly at the start of the next function. But this is not always the case, e.g. if there happens to be alignment padding between the end of one function and the start of the next. In those cases, we may sucessfully look up the function symbol via ResolveSymbolContextForAddress, but *not* set decr_pc_and_recompute_addr_range, and therefore fail to find the correct DWARF CFI record. A very simple fix for this problem is to just never use the first method. Call ResolveSymbolContextForAddress with resolve_tail_call_address set to false, which will cause it to fail if the PC is beyond the end of the current function; or else, identify the next function if the PC is also at the start of the next function. In either case, we will then set the decr_pc_and_recompute_addr_range variable and back up the PC anyway, but this time also find the correct DWARF CFI. A related problem is that the ResolveSymbolContextForAddress sometimes returns a "symbol" with empty name. This turns out to be an ELF section symbol. Now, usually those get type eSymbolTypeInvalid. However, there is code in ObjectFileELF::ParseSymbols that tries to change the type of invalid symbols to eSymbolTypeCode or eSymbolTypeData if the symbol lies within the code or data section. Unfortunately, this check also hits the symbol for the code section itself, which is then marked as eSymbolTypeCode. While the size of the section symbol is 0 according to the ELF file, LLDB considers this size invalid and attempts to figure out the "correct" size. Depending on how this goes, we may end up with a symbol that overlays part of the code section, even outside areas covered by real function symbols. Therefore, if we call ResolveSymbolContextForAddress with PC pointing beyond the end of a function, we may get this bogus section symbol. This again means InitializeNonZerothFrame thinks we have a valid PC, but then we don't find any unwind info for it. The fix for this problem is me to simply always leave ELF section symbols as type eSymbolTypeInvalid. Differential Revision: http://reviews.llvm.org/D18975 llvm-svn: 267363
* Support Linux on SystemZ as platformUlrich Weigand2016-04-1417-0/+1891
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for Linux on SystemZ: - A new ArchSpec value of eCore_s390x_generic - A new directory Plugins/ABI/SysV-s390x providing an ABI implementation - Register context support - Native Linux support including watchpoint support - ELF core file support - Misc. support throughout the code base (e.g. breakpoint opcodes) - Test case updates to support the platform This should provide complete support for debugging the SystemZ platform. Not yet supported are optional features like transaction support (zEC12) or SIMD vector support (z13). There is no instruction emulation, since our ABI requires that all code provide correct DWARF CFI at all PC locations in .eh_frame to support unwinding (i.e. -fasynchronous-unwind-tables is on by default). The implementation follows existing platforms in a mostly straightforward manner. A couple of things that are different: - We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers, since some registers (access register) reside at offsets in the user area that are multiples of 4, but the PTRACE_PEEKUSER interface only allows accessing aligned 8-byte blocks in the user area. Instead, we use a s390 specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that allows accessing a whole block of the user area in one go, so in effect allowing to treat parts of the user area as register sets. - SystemZ hardware does not provide any means to implement read watchpoints, only write watchpoints. In fact, we can only support a *single* write watchpoint (but this can span a range of arbitrary size). In LLDB this means we support only a single watchpoint. I've set all test cases that require read watchpoints (or multiple watchpoints) to expected failure on the platform. [ Note that there were two test cases that install a read/write watchpoint even though they nowhere rely on the "read" property. I've changed those to simply use plain write watchpoints. ] Differential Revision: http://reviews.llvm.org/D18978 llvm-svn: 266308
* Add new ABI callback to provide fallback unwind register locationsUlrich Weigand2016-04-141-26/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the UnwindPlan did not identify how to unwind the stack pointer register, LLDB currently assumes it can determine to caller's SP from the current frame's CFA. This is true on most platforms where CFA is by definition equal to the incoming SP at function entry. However, on the s390x target, we instead define the CFA to equal the incoming SP plus an offset of 160 bytes. This is because our ABI defines that the caller has to provide a register save area of size 160 bytes. This area is allocated by the caller, but is considered part of the callee's stack frame, and therefore the CFA is defined as pointing to the top of this area. In order to make this work on s390x, this patch introduces a new ABI callback GetFallbackRegisterLocation that provides platform- specific fallback register locations for unwinding. The existing code to handle SP unwinding as well as volatile registers is moved into the default implementation of that ABI callback, to allow targets where that implementation is incorrect to override it. This patch in itself is a no-op for all existing platforms. But it is a pre-requisite for adding s390x support. Differential Revision: http://reviews.llvm.org/D18977 llvm-svn: 266307
* Process: fix the build with certain kernel versionsSaleem Abdulrasool2016-04-121-0/+2
| | | | | | | | The structure definitions are not provided, but we perform a sizeof operation of them which causes a build failure. Include `asm/ptrace.h` to get the structure definitions. llvm-svn: 266042
* Reset continue_after_async only if neither SIGINIT nor SIGSTOP received.Oleksiy Vyalov2016-04-081-4/+5
| | | | | | http://reviews.llvm.org/D18886 llvm-svn: 265843
* In GDBRemoteCommunicationClient::GetHostInfo, don't set theJason Molenda2016-04-071-14/+0
| | | | | | | | | | | | | | | | | | 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
* Revert "Reduce code duplication in ProcessGDBRemote"Pavel Labath2016-04-072-20/+39
| | | | | | | In turns out this does make a functional change, in case when the inferior hits an int3 that was not placed by the debugger. Backing out for now. llvm-svn: 265647
* Reduce code duplication in ProcessGDBRemotePavel Labath2016-04-062-39/+20
| | | | | | | | | | | | | | | | Summary: SetThreadStopInfo was checking for a breakpoint at the current PC several times. This merges the identical code into a separate function. I've left one breakpoint check alone, as it was doing more complicated stuff, and it did not see a way to merge that without making the interface complicated. NFC. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18819 llvm-svn: 265560
* Fix a cornercase in breakpoint reportingPavel Labath2016-04-061-0/+17
| | | | | | | | | | | | | | | | | | | | Summary: This resolves a similar problem as D16720 (which handled the case when we single-step onto a breakpoint), but this one deals with involutary stops: when we stop a thread (e.g. because another thread has hit a breakpont and we are doing a full stop), we can end up stopping it right before it executes a breakpoint instruction. In this case, the stop reason will be empty, but we will still step over the breakpoint when do the next resume, thereby missing a breakpoint hit. I have observed this happening in TestConcurrentEvents, but I have no idea how to reproduce this behavior more reliably. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18692 llvm-svn: 265525
* Allow gdbremote process to read modules from memoryStephane Sezer2016-04-052-19/+14
| | | | | | | | | | | | | | | | | | | | | | Summary: The logic to read modules from memory was added to LoadModuleAtAddress in the dynamic loader, but not in process gdb remote. This means that when the remote uses svr4 packets to give library info, libraries only present on the remote will not be loaded. This patch therefore involves some code duplication from LoadModuleAtAddress in the dynamic loader, but removing this would require some amount of code refactoring. Reviewers: ADodds, tberghammer, tfiala, deepak2427, ted Subscribers: tfiala, lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18531 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 265418
* Fix a bug in linux core file handlingPavel Labath2016-04-052-0/+18
| | | | | | | | | | | | | | | | | | | 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
* Set the architecture type from minidump more precisely. Differentiate i686 ↵Adrian McCarthy2016-04-041-2/+10
| | | | | | v i386 when possible. llvm-svn: 265308
* Fixed an issue that could cause debugserver to return two stop reply packets ↵Greg Clayton2016-04-012-4/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ($T packets) for one \x03 interrupt. The problem was that when a \x03 byte is sent to debugserver while the process is running, and up calling: rnb_err_t RNBRemote::HandlePacket_stop_process (const char *p) { if (!DNBProcessInterrupt(m_ctx.ProcessID())) HandlePacket_last_signal (NULL); return rnb_success; } In the call to DNBProcessInterrupt we did: nub_bool_t DNBProcessInterrupt(nub_process_t pid) { MachProcessSP procSP; if (GetProcessSP (pid, procSP)) return procSP->Interrupt(); return false; } This would always return false. It would cause HandlePacket_stop_process to always call "HandlePacket_last_signal (NULL);" which would send an extra stop reply packet _if_ the process is stopped. On a machine with enough cores, it would call DNBProcessInterrupt(...) and then HandlePacket_last_signal(NULL) so quickly that it will never send out an extra stop reply packet. But if the machine is slow enough or doesn't have enough cores, it could cause the call to HandlePacket_last_signal() to actually succeed and send an extra stop reply packet. This would cause problems up in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() where it would get the first stop reply packet and then possibly return or execute an async packet. If it returned, then the next packet that was sent will get the second stop reply as its response. If it executes an async packet, the async packet will get the wrong response. To fix this I did the following: 1 - in debugserver, I fixed "bool MachProcess::Interrupt()" to return true if it sends the signal so we avoid sending the stop reply twice on slower machines 2 - Added a log line to RNBRemote::HandlePacket_stop_process() to say if we ever send an extra stop reply so we will see this in the darwin console output if this does happen 3 - Added response validators to StringExtractorGDBRemote so that we can verify some responses to some packets. 4 - Added validators to packets that often follow stop reply packets like the "m" packet for memory reads, JSON packets since "jThreadsInfo" is often sent immediately following a stop reply. 5 - Modified GDBRemoteCommunicationClient::SendPacketAndWaitForResponseNoLock() to validate responses. Any "StringExtractorGDBRemote &response" that contains a valid response verifier will verify the response and keep looking for correct responses up to 3 times. This will help us get back on track if we do get extra stop replies. If a StringExtractorGDBRemote does not have a response validator, it will accept any packet in response. 6 - In GDBRemoteCommunicationClient::SendPacketAndWaitForResponse we copy the response validator from the "response" argument over into m_async_response so that if we send the packet by interrupting the running process, we can validate the response we actually get in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() 7 - Modified GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() to always check for an extra stop reply packet for 100ms when the process is interrupted. We were already doing this because we might interrupt a process with a \x03 packet, yet the process was in the process of stopping due to another reason. This race condition could cause an extra stop reply packet because the GDB remote protocol says if a \x03 packet is sent while the process is stopped, we should send a stop reply packet back. Now we always check for an extra stop reply packet when we manually interrupt a process. The issue was showing up when our IDE would attempt to set a breakpoint while the process is running and this would happen: --> \x03 <-- $T<stop reply 1> --> z0,AAAAA,BB (set breakpoint) <-- $T<stop reply 1> (incorrect extra stop reply packet) --> c <-- OK (response from z0 packet) Now all packet traffic was off by one response. Since we now have a validator on the response for "z" packets, we do this: --> \x03 <-- $T<stop reply 1> --> z0,AAAAA,BB (set breakpoint) <-- $T<stop reply 1> (Ignore this because this can't be the response to z0 packets) <-- OK -- (we are back on track as this is a valid response to z0) ... As time goes on we should add more packet validators. <rdar://problem/22859505> llvm-svn: 265086
OpenPOWER on IntegriCloud