summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote
Commit message (Collapse)AuthorAgeFilesLines
...
* MingW compilation (windows). Includes various refactoring to improve ↵Virgile Bello2013-08-234-4/+17
| | | | | | portability. llvm-svn: 189107
* Include checksum in non-ack modeEd Maste2013-08-201-6/+3
| | | | | | Patch from Abid, Hafiz. llvm-svn: 188801
* <rdar://problem/13793059>Greg Clayton2013-07-153-10/+79
| | | | | | | | | | | Added a setting to control timeout for kdp response packets. While I was at it, I also added a way to control the response timeout for gdb-remote packets. KDP defaults to 5 seconds, and GDB defaults to 1 second. These were the default values that were in the code prior to adding these settings. (lldb) settings set plugin.process.gdb-remote.packet-timeout 10 (lldb) settings set plugin.process.kdp-remote.packet-timeout 10 llvm-svn: 186360
* <rdar://problem/14182286>Han Ming Ong2013-06-241-2/+2
| | | | | | | | Made sure that temporary object created from HarmonizeThreadIdsForProfileData() doesn’t get passed around without creating an object first. Reviewed by Greg llvm-svn: 184769
* Add some useful logging for tracking thread matching problems.Jim Ingham2013-06-221-0/+24
| | | | llvm-svn: 184619
* <rdar://problem/13980489>Han Ming Ong2013-06-211-1/+1
| | | | | | I added scan type to ‘qGetProfileData’ previously but forgot to update the check to be a substring search. llvm-svn: 184588
* Sort out a number of mismatched integer types in order to cut down the ↵Andy Gibbs2013-06-194-21/+21
| | | | | | number of compiler warnings. llvm-svn: 184333
* Don't retry the Connect when starting up debugserver if the reason for the ↵Jim Ingham2013-06-071-1/+7
| | | | | | | | | | previous failure was EINTR. That means the user was trying to interrupt us, and we should just stop instead. <rdar://problem/13184758> llvm-svn: 183577
* Fix a couple of error message typos.Jim Ingham2013-06-031-2/+2
| | | | llvm-svn: 183145
* Added a test case that verifies that LLDB can debug across a process ↵Greg Clayton2013-05-212-26/+25
| | | | | | | | exec'ing itself into a new program. This currently is only enabled for Darwin since we exec from 64 bit to 32 bit and vice versa for 'x86_64' targets. This can easily be adapted for linux and other platforms, but I didn't want to break any buildbots by assuming it will work. llvm-svn: 182428
* <rdar://problem/13892516>Greg Clayton2013-05-211-3/+20
| | | | | | LLDB can now debug across calls to exec when the architecture changes from say i386 to x86_64 (on darwin). llvm-svn: 182345
* Update ProcessKDP and ProcessMachCore to use ConstString pluginJason Molenda2013-05-112-3/+2
| | | | | | | | | | names when specifying the DynamicLoaderDarwinKernel. ProcessGDBRemote wasn't setting the dyld string any more; remove the remaining code tracking the dyld plugin name altogether from that process plugin. llvm-svn: 181658
* <rdar://problem/13854277>Greg Clayton2013-05-103-16/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <rdar://problem/13594769> Main changes in this patch include: - cleanup plug-in interface and use ConstStrings for plug-in names - Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp - Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging The plug-in interface changes: Modified the lldb_private::PluginInterface class that all plug-ins inherit from: Changed: virtual const char * GetPluginName() = 0; To: virtual ConstString GetPluginName() = 0; Removed: virtual const char * GetShortPluginName() = 0; - Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names. - Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc. llvm-svn: 181631
* Changed the formerly pure virtual function:Greg Clayton2013-05-093-49/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | namespace lldb_private { class Thread { virtual lldb::StopInfoSP GetPrivateStopReason() = 0; }; } To not be virtual. The lldb_private::Thread now handles the correct caching and will call a new pure virtual function: namespace lldb_private { class Thread { virtual bool CalculateStopInfo() = 0; } } This function must be overridden by thead lldb_private::Thread subclass and the only thing it needs to do is to set the Thread::StopInfo() with the current stop reason and return true, or return false if there is no stop reason. The lldb_private::Thread class will take care of calling this function only when it is required. This allows lldb_private::Thread subclasses to be a bit simpler and not all need to duplicate the cache and invalidation settings. Also renamed: lldb::StopInfoSP lldb_private::Thread::GetPrivateStopReason(); To: lldb::StopInfoSP lldb_private::Thread::GetPrivateStopInfo(); Also cleaned up a case where the ThreadPlanStepOverBreakpoint might not re-set its breakpoint if the thread disappears (which was happening due to a bug when using the OperatingSystem plug-ins with memory threads and real threads). llvm-svn: 181501
* Reinstating r181091 and r181106 with fix for Linux regressions.Andrew Kaylor2013-05-072-52/+56
| | | | llvm-svn: 181340
* Temporarily reverting r181091 and r181106 due to the vast test breakage on ↵Ashok Thirumurthi2013-05-072-56/+52
| | | | | | | | | | the Linux buildbots while we develop a better understanding of how to manage the thread lists in a platform-independant fashion. Reviewed by: Daniel Malea llvm-svn: 181323
* After recent OperatingsSystem plug-in changes, the lldb_private::Process and ↵Greg Clayton2013-05-042-52/+56
| | | | | | | | | | lldb_private::Thread subclasses were changed and the API was not respected properly. This checkin aims to fix this. The process now has two thread lists: a real thread list for threads that are created by the lldb_private::Process subclass, and the user visible threads. The user visible threads are the same as the real threas when no OS plug-in in used. But when an OS plug-in is used, the user thread can be a combination of real and "memory" threads. Real threads can be placed inside of memory threads so that a thread appears to be different, but is still controlled by the actual real thread. When the thread list needs updating, the lldb_private::Process class will call the: lldb_private::Process::UpdateThreadList() function with the old real thread list, and the function is expected to fill in the new real thread list with the current state of the process. After this function, the process will check if there is an OS plug-in being used, and if so, it will give the old user thread list, the new real thread list and the OS plug-in will create the new user thread list from both of these lists. If there is no OS plug-in, the real thread list is the user thread list. These changes keep the lldb_private::Process subclasses clean and no changes are required. llvm-svn: 181091
* Recommitting r180831 with trivial fix - remember to return errors if you ↵Jim Ingham2013-05-024-12/+56
| | | | | | compute. llvm-svn: 180898
* <rdar://problem/13700260>Greg Clayton2013-05-014-105/+73
| | | | | | | | | | | | | | <rdar://problem/13723772> Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" key/value pair in each thread dictionary for the OperatingSystemPython plug-ins which allows the core threads to be contained with memory threads. It also allows these memory threads to be stepped, resumed, and controlled just as if they were the actual backing threads themselves. A few things are introduced: - lldb_private::Thread now has a GetProtocolID() method which returns the thread protocol ID for a given thread. The protocol ID (Thread::GetProtocolID()) is usually the same as the thread id (Thread::GetID()), but it can differ when a memory thread has its own id, but is backed by an actual API thread. - Cleaned up the Thread::WillResume() code to do the mandatory parts in Thread::ShouldResume(), and let the thread subclasses override the Thread::WillResume() which is now just a notification. - Cleaned up ClearStackFrames() implementations so that fewer thread subclasses needed to override them - Changed the POSIXThread class a bit since it overrode Thread::WillResume(). It is doing the wrong thing by calling "Thread::SetResumeState()" on its own, this shouldn't be done by thread subclasses, but the current code might rely on it so I left it in with a TODO comment with an explanation. llvm-svn: 180886
* Reverting 180831 as it crashes TestDefaultConstructorForAPIObjects.pyDaniel Malea2013-05-014-56/+12
| | | | llvm-svn: 180868
* Added an option to "process detach" to keep the process stopped, if the ↵Jim Ingham2013-04-304-12/+56
| | | | | | | | | | process plugin (or in the case of ProcessGDBRemote the stub we are talking to) know how to do that. rdar://problem/13680832 llvm-svn: 180831
* Fix one small whitespace alignment mistake.Jason Molenda2013-04-251-6/+6
| | | | llvm-svn: 180242
* <rdar://problem/13697881>Greg Clayton2013-04-201-38/+70
| | | | | | Fixed the GDB remote with the python OS plug-in to not show core threads when they aren't desired and also to have the threads "to the right thing" when continuing. llvm-svn: 179912
* After discussing with Chris Lattner, we require C++11, so lets get rid of ↵Greg Clayton2013-04-181-1/+1
| | | | | | the macros and just use C++11. llvm-svn: 179805
* Since we use C++11, we should switch over to using std::unique_ptr when ↵Greg Clayton2013-04-181-1/+1
| | | | | | | | C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++. Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro. llvm-svn: 179779
* <rdar://problem/13491977>Greg Clayton2013-04-121-2/+6
| | | | | | | | Made some fixes to the OperatingSystemPython class: - If any thread dictionary contains any "core=N" key/value pairs then the threads obtained from the lldb_private::Process itself will be placed inside the ThreadMemory threads and will be used to get the information for a thread. - Cleaned up all the places where a thread inside a thread was causing problems llvm-svn: 179405
* Rationalize how we do Halt-ing before Destroy and Detach.Jim Ingham2013-03-292-101/+3
| | | | | | <rdar://problem/13527167> llvm-svn: 178325
* <rdar://problem/13521159>Greg Clayton2013-03-278-65/+71
| | | | | | | | LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
* Remove my print statements I was using for debugging.Greg Clayton2013-03-091-9/+0
| | | | llvm-svn: 176753
* <rdar://problem/13384282> Greg Clayton2013-03-091-17/+62
| | | | | | | | As much as I hate to leave this hacky code in that adds some d and q registers to ARM registers, I must leave it in. The code is now fixed to not just assume ANY arm target will have registers in a certain order. We now verify the common regs are the same name and byte size before adding the d and q regs. llvm-svn: 176752
* Fix a handful of remaining assumptions that thread IDs were 32-bitsJason Molenda2013-02-232-14/+14
| | | | | | in the gdb-remote Process plugin files. llvm-svn: 175947
* <rdar://problem/13190981>Greg Clayton2013-02-221-4/+5
| | | | | | Fixed an issue where if we got a 'A' async packet back from debugserver, we would resend the last continue command. We now correctly identify the packet as async (just like the 'O' stdout async packet) and we don't resend the continue command. llvm-svn: 175924
* Adding CMake build system to LLDB. Some known issues remain:Daniel Malea2013-02-211-0/+11
| | | | | | | | | | | | | | - generate-vers.pl has to be called by cmake to generate the version number - parallel builds not yet supported; dependency on clang must be explicitly specified Tested on Linux. - Building on Mac will require code-signing logic to be implemented. - Building on Windows will require OS-detection logic and some selective directory inclusion Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir who ported them to Linux! llvm-svn: 175795
* A little cleanup. {Disable/Enable}Breakpoint actually disables/enables ↵Jim Ingham2013-02-152-9/+9
| | | | | | | | | BreakpointSites not breakpoints, it is confusing to have it not named appropriately. Also in StopInfoMachException, we aren't testing for software or not software, just whether the thing is a breakpoint we set. So don't use "software"... llvm-svn: 175241
* <rdar://problem/12693921>Greg Clayton2013-02-141-3/+3
| | | | | | Rename the monitor command from "qCmd" (incorrect) to "qRcmd". llvm-svn: 175191
* <rdar://problem/12693921>Greg Clayton2013-02-011-0/+54
| | | | | | Added the ability to send monitor command to the remote GDB server with "process plugin packet monitor". llvm-svn: 174231
* <rdar://problem/12491235> Jason Molenda2013-01-302-119/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Enhance lldb so it can search for a kernel in memory when attaching to a remote system. Remove some of the code that was doing this from ProcessMachCore and ProcessGDBRemote and put it in DynamicLoaderDarwinKernel. I've added a new setting, plugin.dynamic-loader.darwin-kernel.scan-type which can be set to none - for environments where reading random memory can cause a device crash basic - look at one fixed location in memory for a kernel load address, plus the contents of that address fast-scan - the default, tries "basic" and then looks for the kernel's mach header near the current pc value when lldb connects exhaustive-scan - on 32-bit targets, step through the entire range where the kernel can be loaded, looking for the kernel binary I don't have the setting set up correctly right now, I'm getting back unexpected values from the Property system, but I'll figure that out tomorrow and fix. Besides that, all of the different communication methods / types of kernels appear to be working correctly with these changes. llvm-svn: 173891
* <rdar://problem/13069948>Greg Clayton2013-01-253-16/+16
| | | | | | | | | | | | Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
* <rdar://problem/13072285> Jason Molenda2013-01-251-1/+1
| | | | | | | | | | Change the GDBRemoteRegisterContext::AddRegister function to take its RegisterInfo argument by value instead of using a reference - it will modify the object and modifying the contents of the g_register_infos table in GDBRemoteRegisterContext.cpp can cause a crash the next time we step through it. llvm-svn: 173406
* Changed the register number lists for the qRegisterInfo packet response to ↵Greg Clayton2013-01-211-2/+6
| | | | | | be raw hex to match all other register reading and writing APIs. llvm-svn: 173105
* <rdar://problem/13020634>Greg Clayton2013-01-213-156/+145
| | | | | | | | | | Fixed the 32, 16, and 8 bit pseudo regs for x86_64 (real reg of "rax" which subvalues "eax", "ax", etc...) to correctly get updated when stepping. Also fixed it so actual registers can specify what other registers must be invalidated when a register is modified. Previously, only pseudo registers could invalidate other registers. Modified the LLDB qRegisterInfo extension to the GDB remote interface to support specifying the containing registers with the new "container-regs" key whose value is a comma separated list of register numbers. Also added a "invalidate-regs" key whose value is also a comma separated list of register numbers. Removed the hack GDBRemoteDynamicRegisterInfo::Addx86_64ConvenienceRegisters() function and modified "debugserver" to specify the registers correctly using the new "container-regs" and "invalidate-regs" keys. llvm-svn: 173096
* <rdar://problem/12976277>Han Ming Ong2013-01-183-5/+133
| | | | | | Swap in index ids for thread ids in GDBRemoteCommunicationClient. Besides dealing with the async logic, I have to take care of the situation when the inferior paused as well. llvm-svn: 172869
* <rdar://problem/12976225>Han Ming Ong2013-01-081-2/+16
| | | | | | Checking in the support for doing index ids reservation when given a thread id. llvm-svn: 171904
* <rdar://problem/11961650> Jason Molenda2012-12-193-4/+139
| | | | | | | | | | | | | | | | | Update the debugserver "qProcessInfo" implementation to return the cpu type, cpu subtype, OS and vendor information just like qHostInfo does so lldb can create an ArchSpec based on the returned values. Add a new GetProcessArchitecture to GDBRemoteCommunicationClient akin to GetHostArchitecture. If the qProcessInfo packet is supported, GetProcessArchitecture will return the cpu type / subtype of the process -- e.g. a 32-bit user process running on a 64-bit x86_64 Mac system. Have ProcessGDBRemote set the Target's architecture based on the GetProcessArchitecture when we've completed an attach/launch/connect. llvm-svn: 170491
* Adding events when watchpoints are set or changed.Jim Ingham2012-12-182-7/+8
| | | | | | <rdar://problem/11597849> llvm-svn: 170400
* More Linux warnings fixes (remove default labels as needed):Daniel Malea2012-12-072-3/+0
| | | | | | | | - as per http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations Patch by Matt Kopec! llvm-svn: 169633
* <rdar://problem/12820334>Greg Clayton2012-12-061-2/+2
| | | | | | | | | | | | | I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like: memory read <addr> [<end-addr>] memory write <addr> breakpoint set --address <addr> disassemble --start-address <addr> --end-address <addr> It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers. llvm-svn: 169556
* Fix Linux build warnings due to redefinition of macros:Daniel Malea2012-12-051-0/+2
| | | | | | | | | - add new header lldb-python.h to be included before other system headers - short term fix (eventually python dependencies must be cleaned up) Patch by Matt Kopec! llvm-svn: 169341
* <rdar://problem/12649160>Greg Clayton2012-12-052-0/+14
| | | | | | Added the ability to debug through your process exec'ing itself to the same architecture. llvm-svn: 169340
* Read full 64 bits of kernel address when locating aJason Molenda2012-12-011-1/+1
| | | | | | | 64-bit kernel in ProcessGDBRemote. <rdar://problem/12657369> llvm-svn: 169080
OpenPOWER on IntegriCloud