summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process
Commit message (Collapse)AuthorAgeFilesLines
* 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
* 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
* Add a DiagnosticManager replace error streams in the expression parser.Sean Callanan2016-03-191-37/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix thread/process ID reading from linux core filesPavel Labath2016-03-161-2/+2
| | | | | | | | | | | | | | | | | Summary: This also adds a basic smoke test for linux core file reading. I'm checking in the core files as well, so that the tests can run on all platforms. With some tricks I was able to produce reasonably-sized core files (~40K). This fixes the first part of pr26322. Reviewers: zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18176 llvm-svn: 263628
* This change introduces a "ExpressionExecutionThread" to the ThreadList. Jim Ingham2016-03-121-3/+3
| | | | | | | | | | | | | | | | | | | Turns out that most of the code that runs expressions (e.g. the ObjC runtime grubber) on behalf of the expression parser was using the currently selected thread. But sometimes, e.g. when we are evaluating breakpoint conditions/commands, we don't select the thread we're running on, we instead set the context for the interpreter, and explicitly pass that to other callers. That wasn't getting communicated to these utility expressions, so they would run on some other thread instead, and that could cause a variety of subtle and hard to reproduce problems. I also went through the commands and cleaned up the use of GetSelectedThread. All those uses should have been trying the thread in the m_exe_ctx belonging to the command object first. It would actually have been pretty hard to get misbehavior in these cases, but for correctness sake it is good to make this usage consistent. <rdar://problem/24978569> llvm-svn: 263326
* 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-0717-60/+60
| | | | | | | | | | | | | | 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
* Add support for DW_OP_push_object_address in dwarf expressionsTamas Berghammer2016-02-261-2/+2
| | | | | | | | | Additionally fix the type of some dwarf expression where we had a confusion between scalar and load address types after a dereference. Differential revision: http://reviews.llvm.org/D17604 llvm-svn: 262014
* Fix all of the unannotated switch cases to annotate the fall through or do ↵Greg Clayton2016-02-261-27/+25
| | | | | | the right thing and break. llvm-svn: 261950
* Get register context for the 32-bit process in a WoW64 process minidumpAdrian McCarthy2016-02-252-8/+93
| | | | | | | | | | | | 32-bit processes on 64-bit Windows run in a layer called WoW64 (Windows-on-Windows64). If you capture a mini dump of such a process from a 32-bit debugger, you end up with a register context for the 64-bit WoW64 process rather than the 32-bit one you probably care about. This detects WoW64 by looking to see if there's a module named wow64.dll loaded. For such processes, it then looks in the 64-bit Thread Environment Block (TEB) to locate a copy of the 32-bit CONTEXT record that the plugin needs for the register context. Added some rudimentary tests. I'd like to improve these later once we figure out how to get the exception information from these mini dumps. Differential Revision: http://reviews.llvm.org/D17465 llvm-svn: 261808
* Work around a stepping bug in arm64 android MPavel Labath2016-02-237-95/+354
| | | | | | | | | | | | | | | | | | | | | Summary: On arm64, linux<=4.4 and Android<=M there is a bug, which prevents single-stepping from working when the system comes back from suspend, because of incorrectly initialized CPUs. This did not really affect Android<M, because it did not use software suspend, but it is a problem for M, which uses suspend (doze) quite extensively. Fortunately, it seems that the first CPU is not affected by this bug, so this commit implements a workaround by forcing the inferior to execute on the first cpu whenever we are doing single stepping. While inside, I have moved the implementations of Resume() and SingleStep() to the thread class (instead of process). Reviewers: tberghammer, ovyalov Subscribers: aemerson, rengolin, tberghammer, danalbert, srhines, lldb-commits Differential Revision: http://reviews.llvm.org/D17509 llvm-svn: 261636
* [linux] Remove all traces of signalfd(2)Pavel Labath2016-02-231-1/+0
| | | | | | | | | | | | | | | Summary: Signalfd is not used in the code anymore, and given that the same functionality can be achieved with the new MainLoop class, it's unlikely we will need it in the future. Remove all traces of it. Reviewers: tberghammer, ovyalov Subscribers: tberghammer, danalbert, srhines, lldb-commits Differential Revision: http://reviews.llvm.org/D17510 llvm-svn: 261631
* Make sure code that is in the middle of figuring out the correct architectureJim Ingham2016-02-182-21/+32
| | | | | | | | | on attach uses the architecture it has figured out, rather than the Target's architecture, which may not have been updated to the correct value yet. <rdar://problem/24632895> llvm-svn: 261279
* Revert "Use BKPT instead of UDF for arm/thumb breakpoints"Tamas Berghammer2016-02-161-6/+6
| | | | | | | | | | | This reverts commit 293c18e067d663e0fe93e6f3d800c2a4bfada2b0. The BKPT instruction generates SIGBUS instead of SIGTRAP in the Linux kernel on Nexus 6 - 5.1.1 (kernel version 3.10.40). Revert the CL until we can figure out how can we hanble the SIGBUS or how to get back a SIGTRAP using the BKPT instruction. llvm-svn: 260969
* Add -Wimplicit-fallthrough command line option to clang inJason Molenda2016-02-164-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Additional fix to my change in r259983 to handle theJason Molenda2016-02-131-5/+11
| | | | | | | | | | | case where a core file has a kernel binary and a user process dyld in the same one. Without this, we were always picking the dyld and trying to process it as a kernel. <rdar://problem/24446112> llvm-svn: 260803
* Improve ReadRegister for RegisterContextWindowsx86Adrian McCarthy2016-02-112-30/+27
| | | | | | | | | | | | | | | | | In some circumstances (notably, certain minidumps), the thread CONTEXT does not have values for the control registers (EIP, ESP, EBP, EFLAGS). There are flags in the CONTEXT which indicate which portions are valid, but those flags weren't checked. The old code would not detect this and give a garbage value for the register. The new code will log the problem and return an error. I consolidated the error checking and logging into a helper function, which makes the big switch statement easier to read and verify. Ran tests to ensure this doesn't break anything. Manually verified that a minidump without info on the control registers now indicates the problem instead of giving bad information. Differential Review: http://reviews.llvm.org/D17152 llvm-svn: 260559
* Use BKPT instead of UDF for arm/thumb breakpointsTamas Berghammer2016-02-101-6/+6
| | | | | | | | | The UDF instruction is deprecated in armv7 and in case of thumb2 instructions set it don't work well together with the IT instruction. Differential revision: http://reviews.llvm.org/D16853 llvm-svn: 260367
* ProcessMachCore scans through the core file pages looking for aJason Molenda2016-02-061-0/+32
| | | | | | | | | | | | | | | | | | | | user process dyld binary and/or a mach kernel binary image. By default, it prefers the kernel if it finds both. But if it finds two kernel binary images (which can happen when random things are mapped into memory), it may pick the wrong kernel image. DynamicLoaderDarwinKernel has heuristics to find a kernel in memory; once we've established that there is a kernel binary in memory, call over to that class to see if it can find a kernel address via its search methods. If it does, use that. Some minor cleanups to DynamicLoaderDarwinKernel while I was at it. <rdar://problem/24446112> llvm-svn: 259983
* Add a little logging to ProcessMachCore so it is easier to tell when a user ↵Jason Molenda2016-02-041-3/+16
| | | | | | | | | | process dyld or mach kernel binary are found, and if there are multiples of them found within a single corefile. <rdar://problem/24446112> llvm-svn: 259850
* Provide arguments for all the format string placeholders!Adrian McCarthy2016-02-041-1/+1
| | | | | | Log message was wrong because an argument was missing. llvm-svn: 259793
* Pass socket scheme as part of debug server listen URL.Oleksiy Vyalov2016-02-031-0/+1
| | | | | | http://reviews.llvm.org/D16861 llvm-svn: 259714
* [NetBSD] Remove dead code.Davide Italiano2016-02-031-7/+0
| | | | | PR: http://reviews.llvm.org/D16818 llvm-svn: 259686
* The SetStopInfo from a Mach Exception was setting the stopJim Ingham2016-02-031-0/+2
| | | | | | | | | | reason to None when we stop due to a trace, then noticed that we were on a breakpoint that was not valid for the current thread. That should actually have set it back to trace. This was pr26441 (<rdar://problem/24470203>) llvm-svn: 259684
* Set correct thread stop info when single-step lands on a breakpoint [Windows]Adrian McCarthy2016-02-021-5/+19
| | | | | | | | I don't understand how this worked before, but this fixes the recent test regressions on Windows in TestConsecutiveBreakpoints.py. Differential Revision: http://reviews.llvm.org/D16825 llvm-svn: 259605
* Fix single-stepping onto a breakpointPavel Labath2016-02-022-26/+8
| | | | | | | | | | | | | | | Summary: r259344 introduced a bug, where we fail to perform a single step, when the instruction we are stepping onto contains a breakpoint which is not valid for this thread. This fixes the problem and add a test case. Reviewers: tberghammer, emaste Subscribers: abhishek.aggarwal, lldb-commits, emaste Differential Revision: http://reviews.llvm.org/D16767 llvm-svn: 259488
* NetBSD: Define initial RegisterContextNetBSD_x86_64Kamil Rytarowski2016-02-023-0/+400
| | | | | | | | | | | | Summary: Add basic support, i386 version will be added later. Reviewers: emaste, joerg, clayborg, tfiala Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D16508 llvm-svn: 259462
* Set correct ThreadStopInfo in case of trace eventAbhishek Aggarwal2016-02-012-11/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - The patch solves Bug 23478 and Bug 19311. Resolving Bug 23478 also resolves Bug 23039. Correct ThreadStopInfo is set for Linux and FreeBSD platforms. - Summary: When a trace event is reported, we need to check whether the trace event lands at a breakpoint site. If it lands at a breakpoint site then set the thread's StopInfo with the reason 'breakpoint'. Else, set the reason to be 'Trace'. Change-Id: I0af9765e782fd74bc0cead41548486009f8abb87 Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com> Reviewers: jingham, emaste, lldb-commits, clayborg, ovyalov Subscribers: emaste Differential Revision: http://reviews.llvm.org/D16720 llvm-svn: 259344
* Remove autoconf support from source directories.Eugene Zelenko2016-01-288-136/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
* A while back in revison 244716 we added support for getting the host OS ↵Greg Clayton2016-01-281-1/+2
| | | | | | | | version info from debugserver. We added keys to "qHostInfo" that were "osmajor", "osminor" and "ospatch", but no one ever parsed those, so I am removing them from debugserver. We accidentally also added a "version" key to qHostInfo instead of "os_version". So now we need to support both "version" and "os_version" in qHostInfo since we have debugserver binaries out in the wild that support this old packet type. I have updated debugserver ot use the correct "os_version" for future compatability or correctness. <rdar://problem/24378699> llvm-svn: 259003
* Some 32-bit arm corefiles on darwin may have their general purposeJason Molenda2016-01-202-4/+7
| | | | | | | | | | register set indicated by ARM_THREAD_STATE32 (value 9) instead of the old ARM_THREAD_STATE (value 1); this patch changes lldb to accept either register set flavor code. <rdar://problem/24246257> llvm-svn: 258289
* Update for llvm change. NFC.Rafael Espindola2016-01-181-1/+1
| | | | llvm-svn: 258080
* Add a small refinement to the qSymbol:: support in lldb.Jason Molenda2016-01-132-1/+48
| | | | | | | | | | | | | | | This is a packet which allows the remote gdb stub to ask for the address of a symbol in the process. lldb sends the packet (offering to provide addresses for symbol names) after every solib loaded. I changed lldb so that once the stub has indicated that it doesn't need any more symbol addresses, lldb will stop sending the qSymbol:: packet on new solib loads. This can yield a performance benefit over slower communication links when there are many solibs involved. <rdar://problem/23310049> llvm-svn: 257569
OpenPOWER on IntegriCloud