summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote
Commit message (Collapse)AuthorAgeFilesLines
...
* The RegisterInfo descriptors for the convenience registers can specify an ↵Johnny Chen2012-05-221-1/+1
| | | | | | | | | | offset to be added to the offset as derived from the value_regs field, which is useful for future expansion purposes. As of now, we have: calculated_offset_of_eax = offset_of_rax + (offset_of_eax_from_the_descriptor which is 0) llvm-svn: 157275
* Fix wrong offset of eax and friends pointed out by Greg.Johnny Chen2012-05-221-1/+1
| | | | | | rdar://problem/11487457 llvm-svn: 157272
* rdar://problem/11487457Johnny Chen2012-05-223-0/+80
| | | | | | | | 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
* Include llvm/ADT/STLExtras.h from lldb/Utility/Utils.h and use ↵Johnny Chen2012-05-151-2/+2
| | | | | | llvm::array_lengthof(), instead. llvm-svn: 156876
* Fixed a typo: "aync" => "async"Greg Clayton2012-05-151-8/+8
| | | | llvm-svn: 156797
* <rdar://problem/11240464>Greg Clayton2012-05-152-47/+22
| | | | | | 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-143-52/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-082-20/+53
| | | | | | | | 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
* Remove repeated word.Filipe Cabecinhas2012-05-071-1/+1
| | | | llvm-svn: 156300
* Don't expose the pthread_mutex_t underlying the Mutex & Mutex::Locker classes. Jim Ingham2012-05-041-1/+1
| | | | | | | | | | | | | No one was using it and Locker(pthread_mutex_t *) immediately asserts for pthread_mutex_t's that don't come from a Mutex anyway. Rather than try to make that work, we should maintain the Mutex abstraction and not pass around the platform implementation... Make Mutex::Locker::Lock take a Mutex & or a Mutex *, and remove the constructor taking a pthread_mutex_t *. You no longer need to call Mutex::GetMutex to pass your mutex to a Locker (you can't in fact, since I made it private.) llvm-svn: 156221
* 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
* Patch from Filipe Cabecinhas.Greg Clayton2012-04-261-4/+0
| | | | llvm-svn: 155644
* Missed one place where the assert should have been in a #ifdef. Thanks Jason.Jim Ingham2012-04-201-6/+11
| | | | llvm-svn: 155175
* In debug mode, assert when we fail to get the sequence mutex. We need to ↵Jim Ingham2012-04-191-2/+25
| | | | | | remove as many places where this can happen as possible. llvm-svn: 155138
* Added the thread ID (tid) to each packet history item and the packet history ↵Greg Clayton2012-04-134-42/+95
| | | | | | | | | | 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-132-8/+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
* Remove the GetSequenceMutex timeout that isn't being used in the GDB remote ↵Greg Clayton2012-04-124-16/+40
| | | | | | | | plug-in. Also fixed the ProcessLinux, ProcessPOSIX and ProcessFreeBSD to have the correct UpdateThreadList() prototype. llvm-svn: 154603
* Make sure that DoResume doesn't stall if we shut down the async thread while ↵Jim Ingham2012-04-122-1/+24
| | | | | | | | | | | | | 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-117-105/+72
| | | | | | | | 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-103-2/+27
| | | | | | | | 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-102-15/+84
| | | | | | | | 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-106-18/+21
| | | | | | | | | | | | | | | | 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-094-24/+267
| | | | | | 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
* We sometimes need to be able to call functions (via Process::RunThreadPlan) ↵Jim Ingham2012-04-071-1/+3
| | | | | | | | | | | | from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
* Use integers instead of NULL.Bill Wendling2012-04-031-1/+1
| | | | llvm-svn: 153941
* <rdar://problem/11052174>Greg Clayton2012-03-295-107/+192
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <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
* <rdar://problem/10840355>Greg Clayton2012-03-061-1/+1
| | | | | | Fixed STDERR to not be opened as readable. Also cleaned up some of the code that implemented the file actions as some of the code was using the wrong variables, they now use the right ones (in for stdin, out for stdout, err for stderr). llvm-svn: 152102
* rdar://problem/10652076Johnny Chen2012-03-022-30/+130
| | | | | | | | | | | | | | | | | | | | | | | Add logic to GDBRemoteRegisterContext class to be able to read/write a "composite" register which has "primordial" registers as its constituents. In particular, Read/WriteRegisterBytes() now delegate to Get/SetPrimordialRegister() helper methods to read/write register contents. Also modify RegisterValue class to be able to parse "register write" string value for the NEON quadword registers which is displayed as a vector of uint8's. Example: (lldb) register write q0 "{0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10}" (lldb) register read q0 q0 = {0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10} (lldb) register read --format uint8_t[] s0 s0 = {0x01 0x02 0x03 0x04} (lldb) register read --format uint8_t[] d0 d0 = {0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08} (lldb) register read --format uint8_t[] d1 d1 = {0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10} llvm-svn: 151939
* Fix a typo in comment.Johnny Chen2012-02-291-1/+1
| | | | llvm-svn: 151759
* rdar://problem/10652076Johnny Chen2012-02-291-10/+25
| | | | | | | | Incremental check in to calculate the offsets of registers correctly. Registers can be primordial or composite, for example, r0-r12 are primordial, s0-s31 are primordial, while q0 is composite consisting of (s0, s1, s2, s3). Modify q0-q8 to be composed of the primordial s0-s31 registers. llvm-svn: 151757
* Filled in two missing values when dynamically making register info structs.Greg Clayton2012-02-291-1/+3
| | | | llvm-svn: 151742
* rdar://problem/10652076Johnny Chen2012-02-291-104/+170
| | | | | | | | | | | | | | | | | | | Initial step -- infrastructure change -- to fix the bug. Change the RegisterInfo data structure to contain two additional fields (uint32_t *value_rges and uint32_t *invalidate_regs) to facilitate architectures which have register mapping. Update all existing RegsiterInfo arrays to have two extra NULL's (the additional fields) in each row, GDBRemoteRegisterContext.cpp is modified to add d0-d15 and q0-q15 register info entries which take advantage of the value_regs field to specify the containment relationship: d0 -> (s0, s1) ... d15 -> (s30, s31) q0 -> (d0, d1) ... q15 -> (d30, d31) llvm-svn: 151686
* 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-252-15/+38
| | | | | | Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
* Add a logging mode that takes a callback and flush'es to that callback.Jim Ingham2012-02-212-11/+9
| | | | | | Also add SB API's to set this callback, and to enable the log channels. llvm-svn: 151018
* Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptrGreg Clayton2012-02-215-91/+128
| | | | | | | | | | | | | | | | | 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-092-5/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Switching back to using std::tr1::shared_ptr. We originally switched awayGreg Clayton2012-01-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
* <rdar://problem/10660369>Greg Clayton2012-01-081-1/+1
| | | | | | Fixed the default ARM regiter set to be able to refer to "r7" as "fp" for the apple debugserver. llvm-svn: 147746
* When unwinding from the first frame, try to ask the remote debugserverJason Molenda2011-12-131-7/+35
| | | | | | | | | | | | | | if this is a mapped/executable region of memory. If it isn't, we've jumped through a bad pointer and we know how to unwind the stack correctly based on the ABI. Previously I had 0x0 special cased but if you jumped to 0x2 on x86_64 one frame would be skipped because the unwinder would try using the x86_64 ArchDefaultUnwindPlan which relied on the rbp. Fixes <rdar://problem/10508291> llvm-svn: 146477
* <rdar://problem/10487848>Greg Clayton2011-12-062-3/+11
| | | | | | 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-013-16/+16
| | | | | | | | 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-184-0/+92
| | | | | | | | | | | | | | | | | | | | | | | 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-162-52/+65
| | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud