summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* <rdar://problem/10997402>Greg Clayton2012-03-071-1/+1
| | | | | | | | | | | This fix really needed to happen as a previous fix I had submitted for calculating symbol sizes made many symbols appear to have zero size since the function that was calculating the symbol size was calling another function that would cause the calculation to happen again. This resulted in some symbols having zero size when they shouldn't. This could then cause infinite stack traces and many other side affects. llvm-svn: 152244
* Filled in two missing values when dynamically making register info structs.Greg Clayton2012-02-291-1/+3
| | | | llvm-svn: 151742
* Made a ModuleSpec class in Module.h which can specify a module using one orGreg Clayton2012-02-261-2/+4
| | | | | | | | | | | | | | | | | | more of the local path, platform path, associated symbol file, UUID, arch, object name and object offset. This allows many of the calls that were GetSharedModule to reduce the number of arguments that were used in a call to these functions. It also allows a module to be created with a ModuleSpec which allows many things to be specified prior to any accessors being called on the Module class itself. I was running into problems when adding support for "target symbol add" where you can specify a stand alone debug info file after debugging has started where I needed to specify the associated symbol file path and if I waited until after construction, the wrong symbol file had already been located. By using the ModuleSpec it allows us to construct a module with as little or as much information as needed and not have to change the parameter list. llvm-svn: 151476
* <rdar://problem/3535148>Han Ming Ong2012-02-251-14/+29
| | | | | | Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
* Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptrGreg Clayton2012-02-211-4/+4
| | | | | | | | | | | | | | | | | objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
* Add a general mechanism to wait on the debugger for Broadcasters of a given ↵Jim Ingham2012-02-161-1/+1
| | | | | | | | | class/event bit set. Use this to allow the lldb Driver to emit notifications for breakpoint modifications. <rdar://problem/10619974> llvm-svn: 150665
* First pass at mach-o core file support is in. It currently works for x86_64 Greg Clayton2012-02-091-3/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
* <rdar://problem/10487848>Greg Clayton2011-12-061-3/+4
| | | | | | Protect a member variable from being modified by multiple threads. llvm-svn: 145920
* Process IDs (lldb::pid_t) and thread IDs (lldb::tid_t) are now 64 bit. This Greg Clayton2011-12-011-9/+9
| | | | | | | | will allow us to represent a process/thread ID using a pointer for the OS plug-ins where they might want to represent the process or thread ID using the address of the process or thread structure. llvm-svn: 145644
* Further performance improvements in the DWARF parser:Greg Clayton2011-11-191-1/+1
| | | | | | | | | 1 - the DIE collections no longer have the NULL tags which saves up to 25% of the memory on typical C++ code 2 - faster parsing by not having to run the SetDIERelations() function anymore it is done when parsing the DWARF very efficiently. llvm-svn: 144983
* Added optional calls to lldb_private::Process for getting memory region infoGreg Clayton2011-11-181-0/+9
| | | | | | | | | | | | | | | | | | | | | | | from a process and hooked it up to the new packet that was recently added to our GDB remote executable named debugserver. Now Process has the following new calls: virtual Error Process::GetMemoryRegionInfo (lldb::addr_t load_addr, MemoryRegionInfo &range_info); virtual uint32_t GetLoadAddressPermissions (lldb::addr_t load_addr); Only the first one needs to be implemented by subclasses that can add this support. Cleaned up the way the new packet was implemented in debugserver to be more useful as an API inside debugserver. Also found an error where finding a region for an address actually will pick up the next region that follows the address in the query so we also need ot make sure that the address we requested the region for falls into the region that gets returned. llvm-svn: 144976
* Use a pseudoterminal for local processes if no STDIO redirection or otherGreg Clayton2011-11-171-1/+1
| | | | | | file actions have been specified. llvm-svn: 144922
* Fixed the issue that was causing our monitor process threads to crash, it Greg Clayton2011-11-171-0/+3
| | | | | | | | | | turned out to be unitialized data in the ProcessLaunchInfo default constructor. Turning on MallocScribble in the environment helped track this down. When we launch and attach using the host layer, we now inform the process that it shouldn't detach when by calling an accessor. llvm-svn: 144882
* Made the darwin host layer properly reap any child processes that it spawns.Greg Clayton2011-11-161-49/+62
| | | | | | | | | | | | | | | | | | | | | | After recent changes we weren't reaping child processes resulting in many zombie processes. This was fixed by adding more settings to the ProcessLaunchOptions class that allow clients to specify a callback function and baton to be notified when their process dies. If one is not supplied a default callback will be used that "does the right thing". Cleaned up a race condition in the ProcessGDBRemote class that would attempt to monitor when debugserver died. Added an extra boolean to the process monitor callbacks that indicate if a process exited or not. If your process exited with a zero exit status and no signal, both items could be zero. Modified the process monitor functions to not require a callback function in order to reap the child process. llvm-svn: 144780
* <rdar://problem/10103980>Greg Clayton2011-11-131-40/+0
| | | | | | | A long time ago we started to centralized the STDOUT in lldb_private::Process but we missed a few things still in ProcessGDBRemote. llvm-svn: 144491
* Modified all Process::Launch() calls to use a ProcessLaunchInfo structureGreg Clayton2011-11-031-20/+39
| | | | | | | | on internal only (public API hasn't changed) to simplify the paramter list to the launch calls down into just one argument. Also all of the argument, envronment and stdio things are now handled in a much more centralized fashion. llvm-svn: 143656
* Fix up how we shut down the communication with debugserver so we don't rely onJim Ingham2011-10-281-12/+4
| | | | | | debugserver being responsive to shut down. llvm-svn: 143174
* Cleaned up many error codes. For any who is filling in error strings intoGreg Clayton2011-10-261-3/+3
| | | | | | | | | | | | | lldb_private::Error objects the rules are: - short strings that don't start with a capitol letter unless the name is a class or anything else that is always capitolized - no trailing newline character - should be one line if possible Implemented a first pass at adding "--gdb-format" support to anything that accepts format with optional size/count. llvm-svn: 142999
* If a process plug-in was specified by name, always let the plug-in get used.Greg Clayton2011-10-211-0/+3
| | | | llvm-svn: 142688
* Moved lldb::user_id_t values to be 64 bit. This was going to be needed forGreg Clayton2011-10-191-17/+17
| | | | | | | | | | | process IDs, and thread IDs, but was mainly needed for for the UserID's for Types so that DWARF with debug map can work flawlessly. With DWARF in .o files the type ID was the DIE offset in the DWARF for the .o file which is not unique across all .o files, so now the SymbolFileDWARFDebugMap class will make the .o file index part (the high 32 bits) of the unique type identifier so it can uniquely identify the types. llvm-svn: 142534
* Quiet the default "log enable lldb step" output down a little bit.Jim Ingham2011-10-151-3/+3
| | | | llvm-svn: 142024
* SBValue::Watch() and SBValue::WatchPointee() are now the official API for ↵Johnny Chen2011-10-141-6/+6
| | | | | | | | | | | | | | | | | | creating a watchpoint for either the variable encapsulated by SBValue (Watch) or the pointee encapsulated by SBValue (WatchPointee). Removed SBFrame::WatchValue() and SBFrame::WatchLocation() API as a result of that. Modified the watchpoint related test suite to reflect the change. Plus replacing WatchpointLocation with Watchpoint throughout the code base. There are still cleanups to be dome. This patch passes the whole test suite. Check it in so that we aggressively catch regressions. llvm-svn: 141925
* ProcessGDBRemote::BuildDynamicRegisterInfo() - even if we don't have a ↵Jason Molenda2011-10-061-1/+11
| | | | | | | | | Target architecture set up yet, if we're talking to an Apple arm device set the register set based on the arm device's attributes; this is a safe assumption to make in this particular environment. llvm-svn: 141265
* Cleaned up the the code that figures out the inlined stack frames given a Greg Clayton2011-10-011-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | symbol context that represents an inlined function. This function has been renamed internally to: bool SymbolContext::GetParentOfInlinedScope (const Address &curr_frame_pc, SymbolContext &next_frame_sc, Address &next_frame_pc) const; And externally to: SBSymbolContext SBSymbolContext::GetParentOfInlinedScope (const SBAddress &curr_frame_pc, SBAddress &parent_frame_addr) const; The correct blocks are now correctly calculated. Switched the stack backtracing engine (in StackFrameList) and the address context printing over to using the internal SymbolContext::GetParentOfInlinedScope(...) so all inlined callstacks will match exactly. llvm-svn: 140910
* Added the ability to restrict breakpoints by function name, function regexp, ↵Jim Ingham2011-09-231-1/+1
| | | | | | | | | | selector etc to specific source files. Added SB API's to specify these source files & also more than one module. Added an "exact" option to CompileUnit's FindLineEntry API. llvm-svn: 140362
* Update declarations for all functions/methods that accept printf-styleJason Molenda2011-09-201-1/+1
| | | | | | | | stdarg formats to use __attribute__ format so the compiler can flag incorrect uses. Fix all incorrect uses. Most of these are innocuous, a few were resulting in crashes. llvm-svn: 140185
* Foe x86_64/i386, piggyback the hardware index of the fired watchpoint in the ↵Johnny Chen2011-09-171-1/+2
| | | | | | | | | | exception data sent back to the debugger. On the debugger side, use the opportunity during the StopInfoMachException::CreateStopReasonWithMachException() method to set the hardware index for the very watchpoint location. llvm-svn: 139975
* Fix compiler warnings for GetGDBStoppointType().Johnny Chen2011-09-091-2/+2
| | | | llvm-svn: 139402
* Fill out implementation of Enable/DisableWatchpoint() for ProcessGDBRemote ↵Johnny Chen2011-09-061-4/+46
| | | | | | | | class (Not Tested Yet). Also update the signature of WatchpointLocation::SetEnable() to take a bool as input arg. llvm-svn: 139198
OpenPOWER on IntegriCloud