summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target/Process.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Refactor Unix signals.Chaoren Lin2015-07-141-7/+7
| | | | | | | | | | | | | | | | | | Summary: - Consolidate Unix signals selection in UnixSignals. - Make Unix signals available from platform. - Add jSignalsInfo packet to retrieve Unix signals from remote platform. - Get a copy of the platform signal for each remote process. - Update SB API for signals. - Update signal utility in test suite. Reviewers: ovyalov, clayborg Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11094 llvm-svn: 242101
* Don't select a thread that stopped for a signal that wasJim Ingham2015-07-081-1/+14
| | | | | | | | | not set to stop - there must be some other thread that stopped for a more interesting reason. <rdar://problem/19943567> llvm-svn: 241650
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-251-2/+3
| | | | | | | | | | | | | | | A few extras were fixed - Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected. - Since some places want to access the address as a reference, I added a few new functions to symbol: Address &Symbol::GetAddressRef(); const Address &Symbol::GetAddressRef() const; Linux test suite passes just fine now. <rdar://problem/21494354> llvm-svn: 240702
* Fix the handling of the run lock in cases where you needed to runJim Ingham2015-06-231-7/+12
| | | | | | | | | | | | | a hand-called function from the private state thread. The problem was that on the way out of the private state thread, we try to drop the run lock. That is appropriate for the main private state thread, but not the secondary private state thread. Only the thread that spawned them can know whether this is an appropriate thing to do or not. <rdar://problem/21375352> llvm-svn: 240461
* Fix a variety of typos.Bruce Mitchener2015-06-181-1/+1
| | | | | | No functional change. llvm-svn: 239995
* Fixed a deadlock that was slowing down processes when they shut down. A 3 ↵Greg Clayton2015-06-031-2/+2
| | | | | | second delay could occur sometimes when a process exits, now that delay is gone. llvm-svn: 238893
* Fix a race condition where 2 threads might try to call ↵Greg Clayton2015-06-011-10/+8
| | | | | | | | | | | | Process::SetExitStatus() at the same time. The problem was the mutex was only protecting the setting of m_exit_string and m_exit_string, but this function relies on the m_private_state being set to eStateExited in order to prevent more than 1 client setting the exit status. We want to only allow the first caller to succeed. On MacOSX we have a thread that reaps the process we are debugging, and we also have a thread that monitors the debugserver process. When a process exists, the ProcessGDBRemote::AsyncThread() would set the exit status to the correct value and then another thread would reap the debugserver process and they would often both end up in Process::SetExitStatus() at the same time. With the mutex at the top we allow all variables to be set and the m_private_state to be set to eStateExited _before_ the other thread (debugserver reaped) can try to set th exist status to -1 and "lost connection to debugserver" being set as the exit status. This was probably an issue for lldb-server as well and could very well cleanup some tests that might have been expecting a specific exit status from the process being debugged. llvm-svn: 238794
* Refactor many file functions to use FileSpec over strings.Chaoren Lin2015-05-291-7/+8
| | | | | | | | | | | | | | | | | Summary: This should solve the issue of sending denormalized paths over gdb-remote if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the server handle any denormalization. Reviewers: ovyalov, zturner, vharron, clayborg Reviewed By: clayborg Subscribers: tberghammer, emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D9728 llvm-svn: 238604
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-291-2/+0
| | | | | | | | | | | | | Since interaction with the python interpreter is moving towards being more isolated, we won't be able to include this header from normal files anymore, all includes of it should be localized to the python library which will live under source/bindings/API/Python after a future patch. None of the files that were including this header actually depended on it anyway, so it was just a dead include in every single instance. llvm-svn: 238581
* Change ProcessEventData over to use a std::weak_ptr to a process intead of a ↵Greg Clayton2015-05-291-10/+21
| | | | | | std::shared_ptr. Anyone consuming events for a process should have the process around long enough to grab the event and anyone that holds onto an event for too long won't keep the process around. llvm-svn: 238541
* Fix race in IOHandlerProcessSTDIOPavel Labath2015-05-281-74/+55
| | | | | | | | | | | | | | | | | | Summary: IOHandlerProcessSTDIO::Run() was opening the pipe for interrupt requests lazily. This was racing with another thread executing IOHandlerProcessSTDIO::Cancel() simultaneously. I fix this by opening the pipe in the object constructor. The pipe will be automatically closed when the object is destroyed. Test Plan: Tests pass on linux. Reviewers: clayborg, ribrdb Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10060 llvm-svn: 238423
* I finally found the strong reference that was keeping all ↵Greg Clayton2015-05-281-0/+7
| | | | | | | | | | | | lldb_private::Process instances from ever destroying themselves: ProcessModID.m_mod_id was holding onto the last stop event with ProcessModID::SetStopEventForLastNaturalStopID(EventSP). This is a bad idea because ProcessEventData contains a strong refereence to the process. This is now fixed by calling ProcessModID::SetStopEventForLastNaturalStopID(EventSP()) to clear this event in Process::SetExitStatus() and in Process::Finalize(). This was the original cause of the file descriptor leaks that would cause the test suite to die after running a few hundred processes since no process would ever get destroyed and the communication channel in ProcessGDBRemote and the ProcessIOHandler would never close their pipes. This process leak was previously worked around by closing the pipes when the communication channel was disconnected. This was found by using "ptr_refs" from the heap.py in the lldb.macosx.heap module. It was able to find all strong references to the Process and helped me to figure out who was holding this extra reference. llvm-svn: 238392
* Improve LLDB prompt handlingPavel Labath2015-05-271-51/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix we have in for this is not working all the time and is introducing unnecessary delays. This change does: - Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to lldb-dev. - coordinates printing of asynchronous text with the iohandlers. This is also based on a (different) Greg's patch, but I have added stronger synchronization to it to avoid races. Together, these changes solve the prompt problem for me on linux (both with and without libedit). I think they should behave similarly on Mac and FreeBSD and I think they will not make matters worse for windows. Test Plan: Prompt comes out alright. All tests still pass on linux. Reviewers: clayborg, emaste, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9823 llvm-svn: 238313
* Did some cleanup to stop us from leaking Pipe file descriptors.Greg Clayton2015-05-231-1/+16
| | | | | | | | | | The main issue was the Communication::Disconnect() was calling its Connection::Disconnect() but this wouldn't release the pipes that the ConnectionFileDescriptor was using. We also have someone that is holding a strong reference to the Process so that when you re-run, target replaces its m_process_sp, but it doesn't get destructed because someone has a strong reference to it. I need to track that down. But, even if we have a strong reference to the a process that is outstanding, we need to call Process::Finalize() to have it release as much of its resources as possible to avoid memory bloat. Removed the ProcessGDBRemote::SetExitStatus() override and replaced it with ProcessGDBRemote::DidExit(). Now we aren't leaking file descriptors and the stand alone test suite should run much better. llvm-svn: 238089
* Implement attach to process on Windows.Zachary Turner2015-05-201-1/+5
| | | | | | | Differential Revision: http://reviews.llvm.org/D9801 Reviewed by: Adrian McCarthy llvm-svn: 237817
* Fix handling of hijacked events in synchronous modeIlia K2015-05-201-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch includes the following changes: * Fix Target::Launch to handle hijacked event in synchronous mode * Improve MiStartupOptionsTestCase tests to expect *stopped (MI) * Add SBProcess::GetStopEventForStopID * Add ProcessModID::SetStopEventForLastNaturalStopID/GetStopEventForStopID * Add const qualifier to ProcessModID::GetLastNaturalStopID * Add SBProcess::GetStopEventForStopID * Don't broadcast hijacked event in Target::Launch * Add CMICmnLLDBDebugger::CheckIfNeedToRebroadcastStopEvent/RebroadcastStopEvent Test Plan: ./dotest.py -v --executable $BUILDDIR/bin/lldb tools/lldb-mi/startup_options/ Reviewers: zturner, jingham, clayborg, abidh Reviewed By: clayborg Subscribers: abidh, zturner, lldb-commits, clayborg, jingham Differential Revision: http://reviews.llvm.org/D9371 llvm-svn: 237781
* OperatingSystem plug-ins need to avoid running code when fetching thread ↵Greg Clayton2015-05-151-0/+14
| | | | | | | | | | lists. This patch helps with that by making all SBValue objects that are fetched not try to do dynamic type resolution. Objective C can end up running code to fetch a list of all ISA pointers so we can tell when something is dynamic and this running code could cause the OS plug-in to continue the target. This fix disabled dynamic types, fetches the new threads from the OS plug-in, then restores the setting. <rdar://problem/20768407> llvm-svn: 237465
* Fix Process::ResumeSynchronous which waits a process even in case of errorIlia K2015-04-301-5/+7
| | | | llvm-svn: 236231
* Formatting fix.Jim Ingham2015-04-221-1/+2
| | | | llvm-svn: 235527
* Add a "force_kill" arg to Process::Destroy(). This is needed afterJason Molenda2015-04-171-4/+7
| | | | | | | | | | | | | | | | | | the changes in r233255/r233258. Normally if lldb attaches to a running process, when we call Process::Destroy, we want to detach from the process. If lldb launched the process itself, ::Destroy should kill it. However, if we attach to a process and the driver calls SBProcess::Kill() (which calls Destroy), we need to kill it even if we didn't launch it originally. The force_kill param allows for the SBProcess::Kill method to force the behavior of Destroy. <rdar://problem/20424439> llvm-svn: 235158
* Add new virtual method for language runtime plug-ins:Greg Clayton2015-04-161-1/+17
| | | | | | | | | virtual void LanguageRuntime::ModulesDidLoad (const ModuleList &module_list); Then reorganized how the objective C plug-in is notified so it will work for all LanguageRuntime subclasses. llvm-svn: 235118
* Fix warnings generated by clang-cl.Zachary Turner2015-04-021-1/+1
| | | | | | | | | | | | | | There were a couple of real bugs here regarding error checking and signed/unsigned comparisons, but mostly these were just noise. There was one class of bugs fixed here which is particularly annoying, dealing with MSVC's non-standard behavior regarding the underlying type of enums. See the comment in lldb-enumerations.h for details. In short, from now on please use FLAGS_ENUM and FLAGS_ANONYMOUS_ENUM when defining enums which contain values larger than can fit into a signed integer. llvm-svn: 233943
* Don't return a reference to a temp variable.Greg Clayton2015-04-021-3/+0
| | | | llvm-svn: 233940
* Fix a crasher that could happen when you run LLDB and evaluate an expression ↵Greg Clayton2015-04-021-2/+27
| | | | | | | | | | where the objective C runtime registers a helper function, and also have an Objective C or C++ exception breakpoint. When shutting down the process in Process::Finalize() we clear a STL collection class and that causes objects to be destroyed that could re-enter Process and cause it to try to iterate over that same collection class that is being destroyed. Guard against this by setting a new "m_finalizing" flag that lets us know we are in the process of finalizing. <rdar://problem/20369152> llvm-svn: 233935
* Fix Process::Finalize to do Process::Destroy if needed after r233255Ilia K2015-03-261-2/+20
| | | | llvm-svn: 233258
* Fix -gdb-exit to detach if was attached or destroy otherwise (MI)Ilia K2015-03-261-26/+9
| | | | | | | | | | | | | | | | | Summary: This patch fixes -gdb-exit for locally target. It includes the following changes: # Fix Process::Finalize # Use SBProcess::Destroy in -gdb-exit Reviewers: abidh, zturner, clayborg Reviewed By: clayborg Subscribers: lldb-commits, clayborg, abidh Differential Revision: http://reviews.llvm.org/D8298 llvm-svn: 233255
* Fetch module specification from remote process alsoTamas Berghammer2015-03-241-0/+10
| | | | | | | | | | | | | Previously the remote module sepcification was fetched only from the remote platform. With this CL if we have a remote process then we ask it if it have any information from a given module. It is required because on android the dynamic linker only reports the name of the SO file and the platform can't always find it without a full path (the process can do it based on /proc/<pid>/maps). Differential revision: http://reviews.llvm.org/D8547 llvm-svn: 233061
* Move some functions from source/lldb.cpp to Utility.Zachary Turner2015-03-181-0/+1
| | | | | | | | | | Specifically, there were some functions for converting enums to strings and a function for matching a string using a specific matching algorithm. This moves those functions to more appropriate headers in lldb/Utility and updates references to include the new headers. llvm-svn: 232673
* Move lldb-log.cpp to core/Logging.cppZachary Turner2015-03-181-3/+0
| | | | | | | | | So that we don't have to update every single #include in the entire codebase to #include this new header (which used to get included by lldb-private-log.h, we automatically #include "Logging.h" from within "Log.h". llvm-svn: 232653
* Fix broadcasters for interpreter and process:Ilia K2015-03-171-1/+1
| | | | | | | | # Fix CommandInterpreter.Broadcaster name (it should be the same as CommandInterpreter::GetStaticBroadcasterClass()) # Prevent the same error in Process.Broadcaster # Fix SBCommandInterpreter::GetBroadcasterClass (it should call CommandInterpreter::GetStaticBroadcasterClass(), was Communication::GetStaticBroadcasterClass()) llvm-svn: 232500
* Fix ProcessIO test failuresPavel Labath2015-03-121-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: There was a race condition regarding the output of the inferior process. The reading of the output is performed on a separate thread, and there was no guarantee that the output will get eventually consumed. Because of that, it was happening that calling Process::GetSTDOUT was not returning anything even though the process was terminated and would definitely not produce any further output. This was usually happening only under very heavy system load, but it can be reproduced by placing an usleep in the stdio thread (Process::STDIOReadThreadBytesReceived). This patch addresses this by adding synchronization capabilities to the Communication thread. After calling Communication::SynchronizeWithReadThread one can be sure that all pending input has been processed by the read thread. This function is then called after every public event which stops the process to obtain the entire process output. Test Plan: TestProcessIO.py should now succeed every time instead of flaking in and out. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D8246 llvm-svn: 232023
* Fix race condition with -o "process launch" on linuxPavel Labath2015-03-061-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Summary: starting a debug session on linux with -o "process launch" lldb parameter was failing since Target::Launch (in sychronous mode) is expecting to be able to receive public process events. However, PlatformLinux did not set up event hijacking on process launch, which caused these events to be processed elsewhere and left Target::Launch hanging. This patch enables event interception in PlatformLinux (which was commented out). Upon enabling event interception, I noticed an issue, which I traced back to the inconsistent state of public run lock, which remained false even though public and private process states were "stopped". I addressed this by making sure the run lock is "stopped" upon exit from WaitForProcessToStop (which already had similar provisions for other return paths). Test Plan: This should fix the intermittent TestFormats failure we have been experiencing on Linux. Reviewers: jingham, clayborg, vharron Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D8079 llvm-svn: 231460
* Further reduce header footprint of Debugger.h.Zachary Turner2015-03-041-0/+1
| | | | llvm-svn: 231202
* Further reduce the header footprint of Process.hZachary Turner2015-03-031-1/+61
| | | | | | | No functional change here, only deletes unnecessary headers and moves one function's body from the .h file to the .cpp. llvm-svn: 231145
* Revert "Fix warnings found with clang-cl."Zachary Turner2015-02-251-1/+1
| | | | | | | SWIG doesn't like enum : unsigned. Revert this until I can fix this in a way that swig likes. llvm-svn: 230531
* Fix warnings found with clang-cl.Zachary Turner2015-02-251-1/+1
| | | | | | | | | | | Earlier this week I was able to get clang-cl on Windows to be able to self host. This opened the door to being able to get a whole new slew of warnings for the Windows build. This patch fixes all of the warnings, many of which were real bugs. llvm-svn: 230522
* Set error status when failed to catch stop after launchTamas Berghammer2015-02-231-0/+1
| | | | | | | | | | | Process::Launch try to catch a stop signal after launching a process. If it is unsuccessful it destroy the process but previously still reported that the process launched successfully. This behavior caused a deadlock. With thic change the process launch error reported correctly. Differential revision: http://reviews.llvm.org/D7784 llvm-svn: 230212
* Rename the "glob arguments" feature to "shell expand arguments"Enrico Granata2015-02-201-5/+5
| | | | | | This should not bring any feature change, except changing names of things here and there llvm-svn: 230077
* Make sure the public state is eStateStopped when we return from ↵Greg Clayton2015-02-201-2/+2
| | | | | | SBTarget::LoadCore() by hijacking the public event queue so we can ensure that the event gets consumed and the public state of the process (StateType SBProcess::GetState()) returns eStateStopped. llvm-svn: 230066
* Avoid a race condition when loading core files where the process might still ↵Greg Clayton2015-02-201-1/+17
| | | | | | | | be handling the eStateStopped event we post to the private state thread causing us to return from SBTarget::LoadCore() before the process is ready to have API calls used on it. This fixes a crasher that could happen when loading core files from scripts. llvm-svn: 230060
* Add extra check that target was stopped before the *stopped is sent.Ilia K2015-02-111-1/+1
| | | | | | This patch fixes r228417. It's required because eStateCrushed case wasn't investigated. llvm-svn: 228824
* Fix 'process launch -i' for remote processesVince Harron2015-02-101-2/+2
| | | | | | | | | | | | | | | | | | We want to forward stdin when stdio is not disabled and when we're not redirecting stdin from a file. renamed m_stdio_disable to m_stdin_forward and inverted value because that's what we want to remember. There was previously a bug that if you redirected stdin from a file, stdout and stderr would also be redirected to /dev/null Adds support for remote target to TestProcessIO.py Fixes ProcessIOTestCase.test_stdin_redirection_with_dwarf for remote Linux targets llvm-svn: 228744
* Add a "launch with globber" mode that lets you launch a process after having ↵Enrico Granata2015-02-101-2/+13
| | | | | | globbed the command line arguments via argdumper instead of routing via /bin/sh llvm-svn: 228658
* Add support for SBProcess::PutSTDIN to remote processesVince Harron2015-02-061-0/+2
| | | | | | | | | | | | | | Processes running on a remote target can already send $O messages to send stdout but there is no way to send stdin to a remote inferior. This allows processes using the API to pump stdin into a remote inferior process. It fixes a hang in TestProcessIO.py when running against a remote target. llvm-svn: 228419
* Fix a missing "*stopped" notification in LLDB-MI after "process launch -s" ↵Ilia K2015-02-061-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in case of remote-macosx Summary: This patch fixes *stopped notification for remote target when started with eLaunchFlagStopAtEntry (for example, using "process launch -s"). See explanation below: ``` Target::Launch (ProcessLaunchInfo &launch_info, Stream *stream) { ... if (state != eStateConnected && platform_sp && platform_sp->CanDebugProcess ()) { ... } else { ... if (m_process_sp) error = m_process_sp->Launch (launch_info); } if (error.Success()) { if (launch_info.GetFlags().Test(eLaunchFlagStopAtEntry) == false) { .... } -- missing event if eLaunchFlagStopAtEntry is set -- m_process_sp->RestoreProcessEvents (); } ... return error ``` Also this patch contains tests and you can check how it works. Reviewers: zturner, clayborg, abidh Reviewed By: clayborg Subscribers: clayborg, abidh, zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D7273 llvm-svn: 228417
* Fix a race condition where you could set the selected thread & target in theJim Ingham2015-01-191-1/+2
| | | | | | | | | | CommandInterpreter's execution context AFTER the process had started running and before it initially stopped. Also fixed one test case that was implicitly using this (and an abuse of the async mode) to accidentally succeed. <rdar://problem/16814726> llvm-svn: 226528
* Fixed an issue where if the operating system python plug-in is changed at ↵Greg Clayton2015-01-131-10/+33
| | | | | | | | | | | | | | | | | | | | | | | runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
* Enhance the Pipe interface for better portability.Zachary Turner2014-12-171-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes a number of improvements to the Pipe interface. 1) An interface (PipeBase) is provided which exposes pure virtual methods for any implementation of Pipe to override. While not strictly necessary, this helps catch errors where the interfaces are out of sync. 2) All methods return lldb_private::Error instead of returning bool or void. This allows richer error information to be propagated up to LLDB. 3) A new ReadWithTimeout() method is exposed in the base class and implemented on Windows. 4) Support for both named and anonymous pipes is exposed through the base interface and implemented on Windows. For creating a new pipe, both named and anonymous pipes are supported, and for opening an existing pipe, only named pipes are supported. New methods described in points #3 and #4 are stubbed out on posix, but fully implemented on Windows. These should be implemented by someone on the linux / mac / bsd side. Reviewed by: Greg Clayton, Oleksiy Vyalov Differential Revision: http://reviews.llvm.org/D6686 llvm-svn: 224442
* Make the platform process connect path less chatty.Stephane Sezer2014-12-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If a stream contains an empty string, no need to append it to the output (otherwise we end up with a blank line). Also, no need to print a status message when the state changes to connected, as this string brings no information -- "Process 0" does not mean anything to the user, and the process being connected has no meaning either. Test Plan: Connect to a remote linux platform mode daemon with `platform select remote-linux` followed by `platform connect ...`, create a target and run it, observe the output. Also, run the full test suite (dosep.py). Before: (lldb) [...] connect, etc. (lldb) r Process 0 connected Process 5635 launched: '/Users/sas/Source/test' (x86_64) Process 5635 stopped After: (lldb) [...] connect, etc. (lldb) r Process 5635 launched: '/Users/sas/Source/test' (x86_64) Process 5635 stopped Reviewers: tfiala, vharron, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D6593 llvm-svn: 224188
* Handle thumb IT instructions correctly all the time.Greg Clayton2014-12-091-0/+9
| | | | | | | | | | | | | | | | | | | | | | The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true. When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction. The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match. To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed. This patch does the following: 1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb 2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute 3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb 4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below) This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added. <rdar://problem/19145455> llvm-svn: 223851
OpenPOWER on IntegriCloud