summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add support for libdispatch version 4 structure layout for findingJason Molenda2012-11-101-7/+24
| | | | | | | | | | GCD queue names of threads to ProcessGDBRemote::GetDispatchQueueNameForThread() May need tweaking once this version is rolled out but visual inspection looks fine. <rdar://problem/12333100> llvm-svn: 167667
* Remove a debugging printf that was left in the code.Greg Clayton2012-11-091-1/+0
| | | | llvm-svn: 167637
* Removed use of non-standard escape character '\%'Filipe Cabecinhas2012-11-091-1/+1
| | | | llvm-svn: 167636
* There seems to be some odd corner case where we shut down the ↵Jim Ingham2012-11-011-12/+51
| | | | | | | | ProcessGDBRemote, but we haven't managed to shut down the async thread. That causes the ProcessGDBRemote::AsyncThread to crash when it wakes up. So I changed StartAsyncThread and StopAsyncThread to be callable multiple times (only the first one does anything) so that we can just shut it down unequivocally in the ProcessGDBRemote destructor. <rdar://problem/12602981> llvm-svn: 167197
* If we got what looks like a single step exception but we weren't single ↵Jim Ingham2012-10-271-3/+7
| | | | | | | | stepping then just report the raw exception. llvm-svn: 166859
* <rdar://problem/12491387>Greg Clayton2012-10-191-2/+2
| | | | | | | | | | Added commands to the KDP plug-in that allow sending raw commands through the KDP protocol. You specify a command byte and a payload as ASCII hex bytes, and the packet is created with a valid header/sequenceID/length and sent. The command responds with a raw ASCII hex string that contains all bytes in the reply including the header. An example of sending a read register packet for the GPR on x86_64: (lldb) process plugin packet send --command 0x07 --payload 0100000004000000 llvm-svn: 166346
* Added "process plugin packet send" and "process plugin packet history" for ↵Greg Clayton2012-10-151-8/+106
| | | | | | GDB remote. "process plugin packet send" will send a packet and receive a response. "process plugin packet history" will dump the packet history buffer. llvm-svn: 165991
* <rdar://problem/12491387>Greg Clayton2012-10-131-1/+57
| | | | | | | | | | | I added the ability for a process plug-in to implement custom commands. All the lldb_private::Process plug-in has to do is override: virtual CommandObject * GetPluginCommandObject(); This object returned should be a multi-word command that vends LLDB commands. There is a sample implementation in ProcessGDBRemote that is hollowed out. It is intended to be used for sending a custom packet, though the body of the command execute function has yet to be implemented! llvm-svn: 165861
* Change the Thread constructor over to take a Process& rather than a ↵Jim Ingham2012-10-101-2/+2
| | | | | | | | | | | | | ProcessSP. We can't create Threads with a NULL ProcessSP, so it makes no sense to use the SP. Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame changes the stack. Made the Driver use this notification to print the new thread status rather than doing it in the command. Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call. <rdar://problem/12383087> llvm-svn: 165640
* In ↵Jason Molenda2012-10-061-0/+5
| | | | | | | | | | | | | | | | | | DynamicLoaderDarwinKernel::OSKextLoadedKextSummary::LoadImageUsingMemoryModule(), if we have a kernel binary, set the target's architecture to match. Include the target's architecture in the ModuleSpec when we're searching for the kext binaries on the local system -- otherwise we won't get a specific slice of a fat file picked out for us and we won't use the returned Module correctly. Remove the redundant attempt to find a file on the local filesystem from this method. In ProcessGDBRemote::CheckForKernel(), if we have a kernel binary in memory, mark the canJIT as false. There is no jitting code in kernel debug sessions. llvm-svn: 165357
* Don't turn on the debugserver log by default.Jim Ingham2012-10-031-2/+2
| | | | llvm-svn: 165176
* The kernel loading code is now isolated in the DynamicLoaderDarwinKernel;Jason Molenda2012-10-031-103/+30
| | | | | | | | | | remove the duplicates of this code in ProcessGDBRemote and ProcessKDP. These two Process plugins will hardcode their DynamicLoader name to be the DynamicLoaderDarwinKernel so the correct DynamicLoader is picked, and return the kernel load address as the ImageInfosAddress. <rdar://problem/12417038> llvm-svn: 165080
* Add the RelocateOrLoadKernel and LoadKernel methods to ↵Jason Molenda2012-09-291-18/+191
| | | | | | | | | | | | | | ProcessGDBRemote::DoRemoteConnect(). When attaching to a remote system that does not look like a typical vendor system, and no executable binary was specified to lldb, check a couple of fixed locations where kernels running in ASLR mode (slid in memory to a random address) store their load addr when booted in debug mode, and relocate the symbols or load the kernel wholesale from the host computer if we can find it. <rdar://problem/7714201> llvm-svn: 164888
* Add support for debugging KASLR kernels via kdp (the kernel beingJason Molenda2012-09-291-1/+20
| | | | | | | | | | | | | | | | | | loaded at a random offset). To get the kernel's UUID and load address I need to send a kdp packet so I had to implement the kernel relocation (and attempt to find the kernel if none was provided to lldb already) in ProcessKDP -- but this code really properly belongs in DynamicLoaderDarwinKernel. I also had to add an optional Stream to ConnectRemote so ProcessKDP::DoConnectRemote can print feedback about the remote kernel's UUID, load address, and notify the user if we auto-loaded the kernel via the UUID. <rdar://problem/7714201> llvm-svn: 164881
* <rdar://problem/11752499>Greg Clayton2012-09-191-6/+6
| | | | | | Improve error messages when memory read/write fails. llvm-svn: 164188
* Stop using the "%z" size_t modifier and cast all size_t values to uint64_t. ↵Greg Clayton2012-09-181-3/+3
| | | | | | Some platforms don't support this modification. llvm-svn: 164148
* Typed too fast adding lockers. Actually put them in a locker.Jim Ingham2012-09-111-2/+2
| | | | llvm-svn: 163575
* <rdar://problem/11757916>Greg Clayton2012-08-291-0/+1
| | | | | | | | | | | | Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
* Added Args::StringForEncoding(), Args::StringToGenericRegister() and ↵Greg Clayton2012-08-241-36/+8
| | | | | | | | centralized the parsing of the string to encoding and string to generic register. Added code the initialize the register context in the OperatingSystemPython plug-in with the new PythonData classes, and added a test OperatingSystemPython module in lldb/examples/python/operating_system.py that we can use for testing. llvm-svn: 162530
* Cope with the case where the user-supplied callbacks want the watchpoint ↵Johnny Chen2012-08-231-0/+4
| | | | | | | | | | | | itself to be disabled! Previously we put a WatchpointSentry object within StopInfo.cpp to disable-and-then-enable the watchpoint itself while we are performing the actions associated with the triggered watchpoint, which can cause the user-initiated watchpoint disabling action to be negated. Add a test case to verify that a watchpoint can be disabled during the callbacks. llvm-svn: 162483
* Added a test for the Python part of SBInputReader callbacks.Filipe Cabecinhas2012-08-221-2/+6
| | | | llvm-svn: 162357
* Added an lldb_private & equivalent SB API to send an AsyncInterrupt to the ↵Jim Ingham2012-07-271-1/+1
| | | | | | | | | | | | | | event loop. Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the event loop. If you are attaching and get an async interrupt, abort the attach attempt. Also remember to destroy the process if get interrupted while attaching. Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends. <rdar://problem/10792425> llvm-svn: 160903
* Provide subdir of StopInfoMachException.h in #include.Jason Molenda2012-07-251-1/+1
| | | | llvm-svn: 160704
* Add "vAttachOrWait" to debugserver, so you can implement "attach to the ↵Jim Ingham2012-07-201-1/+14
| | | | | | process if it exists OR wait for it" without race conditions. Use that in lldb. llvm-svn: 160578
* Changed ProcessGDBRemote to avoid the reservedSean Callanan2012-07-191-1/+14
| | | | | | | | | port range. Also added a comment indicating that more work is needed. <rdar://problem/11580051> llvm-svn: 160514
* Ran the static analyzer on the codebase and found a few things.Greg Clayton2012-07-171-9/+1
| | | | llvm-svn: 160338
* <rdar://problem/11782789> Changes to the watchpoint implementation on ARM so ↵Enrico Granata2012-07-131-0/+7
| | | | | | that we single-step before stopping at the WP. This is necessary because on ARM the WP triggers before the opcode is actually executed, so we would be unable to continue since we would keep hitting the WP. We work around this by disabling the WP, single stepping and then putting the WP back in place. llvm-svn: 160199
* If we hit a breakpoint but there's a thread specifier which doesn't match ↵Jim Ingham2012-07-111-8/+14
| | | | | | this thread, return no stop reason. llvm-svn: 160080
* Work around some problems destroying a process with older debugservers.Jim Ingham2012-07-041-1/+108
| | | | | | rdar://problem/11359989 llvm-svn: 159697
* Add an "extra-startup-commands" process setting so we can send some command ↵Jim Ingham2012-07-021-0/+8
| | | | | | strings to the actual process plugin to interpret as it wishes. llvm-svn: 159511
* Change the Mutex::Locker class so that it takes the Mutex object and locks ↵Jim Ingham2012-06-081-3/+0
| | | | | | | | | | | | | | it, rather than being given the pthread_mutex_t from the Mutex and locks that. That allows us to track ownership of the Mutex better. Used this to switch the LLDB_CONFIGURATION_DEBUG enabled assert when we can't get the gdb-remote sequence mutex to assert when the thread that had the mutex releases it. This is generally more useful information than saying just who failed to get it (since the code that had it locked often had released it by the time the assert fired.) llvm-svn: 158240
* rdar://problem/11487457Johnny Chen2012-06-081-1/+2
| | | | | | | Previous fix to add convenience registers for x86_64 did not take the 'process attach' scenario into account. This patch fixes that. llvm-svn: 158222
* Fix a place in ↵Jim Ingham2012-06-061-3/+33
| | | | | | | | | | | GDBRemoteCommunicationClient::SendContinuePacketAndWaitForReply where we weren't taking m_interrupt_sent into account. Also don't reset m_interrupt_sent in SendInterrupt but do so in SendPacketAndWaitForResponse when we know we've handled the interrupt. Fix a code path through ProcessGDBRemote::DoDestroy where we were tearing down the debug session but not setting the exit status. llvm-svn: 158043
* Add the capability to display the number of supported hardware watchpoints ↵Johnny Chen2012-05-231-0/+8
| | | | | | | | | to the "watchpoint list" command. Add default Process::GetWatchpointSupportInfo() impl which returns an error of "not supported". Add "qWatchpointSupportInfo" packet to the gdb communication layer to support this, and modify TestWatchpointCommands.py to test it. llvm-svn: 157345
* extra ';' outside of a function [-pedantic,-Wextra-semi]Filipe Cabecinhas2012-05-231-1/+1
| | | | llvm-svn: 157330
* rdar://problem/11487457Johnny Chen2012-05-221-0/+4
| | | | | | | | Add convenience registers eax, ebx, ecx, edx, edi, esi, ebp, esp to the 'register read' command for x86_64. Add a GDBRemoteRegisterContext::Addx86_64ConvenienceRegisters() method called from ProcessGDBRemote::BuildDynamicRegisterInfo(). Servicing of eax, for example, is accomplished by delegating to rax with an adjusted offset into the register context. llvm-svn: 157230
* Make sure that our thread list can't get out of date like was happening ↵Greg Clayton2012-05-161-0/+6
| | | | | | before Jims fix in revision 156894. llvm-svn: 156898
* <rdar://problem/11240464>Greg Clayton2012-05-151-45/+19
| | | | | | Correctly unique a class' methods when we detect that a class has been uniqued to another. llvm-svn: 156795
* Fix missing NEON registers for the 'register read' command with the lldb ↵Johnny Chen2012-05-141-17/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | debugserver which supports the 'qRegisterInfo' packet that dynamically discovers remote register context information. o GDBRemoteRegisterContext.h: Change the prototype of HardcodeARMRegisters() to take a boolean flag, which now becomes void HardcodeARMRegisters(bool from_scratch); o GDBRemoteRegisterContext.cpp: HardcodeARMRegisters() now checks the from_scratch flag and decides whether to add composite registers to the already existing primordial registers based on a table called g_composites which describes the composite registers. o ProcessGDBRemote.cpp: Modify the logic of ProcessGDBRemote::BuildDynamicRegisterInfo() to call m_register_info.HardcodeARMRegisters() with the newly introduced 'bool from_scrach' flag. rdar://problem/10652076 llvm-svn: 156773
* <rdar://problem/11358639>Greg Clayton2012-05-081-7/+8
| | | | | | | | Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples. Also make the selection process for auto selecting platforms based off of an arch much better. llvm-svn: 156354
* In ProcessGDBRemote::DoConnectRemote(), if the remote system informedJason Molenda2012-05-031-0/+8
| | | | | | | | | | | | | | us of its architecture, use that to set the Target's arch if it doesn't already have one set. In Process::CompleteAttach(), if the Target has a valid arch make sure that the Platform we pick up is compatible with that arch; if not, find a Platform that is compatible. Don't let the the default platform override the Target's arch. <rdar://problem/11185420> llvm-svn: 156116
* Added the thread ID (tid) to each packet history item and the packet history ↵Greg Clayton2012-04-131-1/+5
| | | | | | | | | | now always dumps to a lldb_private::Stream. Enable logging the packet history when registers fail to read due to not getting the sequence mutex if "--verbose" is enabled on the log channel for the "gdb-remote" log category. This will help us track down some issues. llvm-svn: 154704
* <rdar://problem/11241798>Greg Clayton2012-04-131-7/+4
| | | | | | The less locks there are, the better. I removed the thread ID mutex and now just shared the m_thread_list's mutex to make sure we don't deadlock due to lock inversion. llvm-svn: 154652
* Make sure that DoResume doesn't stall if we shut down the async thread while ↵Jim Ingham2012-04-121-0/+22
| | | | | | | | | | | | | DoResume is waiting for packet confirmation. Also added a bit more logging. Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state thread so that the Process can shut down cleanly. <rdar://problem/11228538> llvm-svn: 154601
* No functionality changes, mostly cleanup.Greg Clayton2012-04-111-12/+3
| | | | | | | | Cleaned up the Mutex::Locker and the ReadWriteLock classes a bit. Also cleaned up the GDBRemoteCommunication class to not have so many packet functions. Used the "NoLock" versions of send/receive packet functions when possible for a bit of performance. llvm-svn: 154458
* Added a new packet to our GDB remote protocol:Greg Clayton2012-04-101-2/+4
| | | | | | | | QListThreadsInStopReply This GDB remote query command can enable added a "threads" key/value pair to all stop reply packets so that we always get a list of all threads in each stop reply packet. It increases performance if enabled (the reply to the "QListThreadsInStopReply" is "OK") by saving us from sending to command/reply pairs (the "qfThreadInfo" and "qsThreadInfo" packets), and also helps us keep the current process state up to date. llvm-svn: 154380
* A general stability fix where we _always_ get the thread list immediately ↵Greg Clayton2012-04-101-15/+76
| | | | | | | | after we get the stop packets. We had some racy conditions where thread 1 might be sending a packet and thread 2 tries to send a packet to get the thread list and it fails and ends up with an empty list. Packets use a sequence mutex to be able to ensure when you send a packet, you get the resonse. This sequence mutex is take when the process is running, and as we exit the running state and notify our process with the stop packet, we now always get the thread ID list before we do anything and before we can run into race conditions. The next step is to have our stop reply packets send the thread list in the actual stop reply packet to avoid a 2 packet overhead of sending the qfThreadInfo + response and qfThreadInfo + response. llvm-svn: 154376
* Trying to solve our disappearing thread issues by making thread list updates ↵Greg Clayton2012-04-101-4/+10
| | | | | | | | | | | | | | | | safer. The current ProcessGDBRemote function that updates the threads could end up with an empty list if any other thread had the sequence mutex. We now don't clear the thread list when we can't access it, and we also have changed how lldb_private::Process handles the return code from the: virtual bool Process::UpdateThreadList (lldb_private::ThreadList &old_thread_list, lldb_private::ThreadList &new_thread_list) = 0; A bool is now returned to indicate if the list was actually updated or not and the lldb_private::Process class will only update the stop ID of the validity of the thread list if "true" is returned. The ProcessGDBRemote also got an extra assertion that will hopefully assert when running debug builds so we can find the source of this issue. llvm-svn: 154365
* Added a packet history object to the GDBRemoteCommunication class that is ↵Greg Clayton2012-04-091-0/+14
| | | | | | always remembering the last 512 packets that were sent/received. These packets get dumped if logging gets enabled, or when the new expr lldb::DumpProcessGDBRemotePacketHistory (void *process, const char *log_file_path) global function is called. llvm-svn: 154354
* <rdar://problem/11052174>Greg Clayton2012-03-291-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <rdar://problem/11051056> Found a race condition when sending async packets in the ProcessGDBRemote. A little background: GDB remote clients can only send one packet at a time. You must send a packet and wait for a response. So when we continue, we obviously can't hold up the calling thread waiting for the process to stop again, so we have an async thread in the ProcessGDBRemote whose only job is to run packets that control the inferior process. When you send a continue packet, the only packet you can send is an interrupt packet (which consists of sending a CTRL+C (or a '\x03' byte)). This then stops the inferior and we can send the async packet, and then resume the target. There was a race condition that often happened during stepping where we are doing a source level single step which consists of many instruction steps and a few runs here and there when we step into a function. So the flow looks like: inst single step inst single step inst single step inst single step inst single step step BP and run inst single step inst single step inst single step Now if we got an async packet while the program is running we get something like: send --> continue send --> interrupt recv <-- interrupt stop reply packet send --> async packet recv <-- async response send --> continue again and wait for actual stop Problems arise when this was happening when single stepping a thread where we would get: send --> step thread 123 send --> interrupt send --> stop reply for thread 123 (from the step) Now we _might_ have an extra stop reply packet from the "interrupt" which we weren't checking for and we could end up with: send --> async packet (like memory read!) recv <-- async response (which is the interrupt stop reply packet) Now we have the read memroy reply sitting in our buffer and waiting to be used as the reply for the next packet... To further complicate things, the single step should have exited the async thread since the run control is finished, but now it will continue if it was interrupted. The fixes I checked in to two major things: - watch for the extra stop reply if we need to - make sure we exit from the async thread run loop when the previous run control (like the instruction level single step) is finished. Needless to say this makes very fast stepping in Xcode much more reliable. llvm-svn: 153629
OpenPOWER on IntegriCloud