summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote
Commit message (Collapse)AuthorAgeFilesLines
* Unfortunately, sranddev() is not available on all platforms so seed using theStephen Wilson2011-03-301-1/+4
| | | | | | current time instead. llvm-svn: 128514
* Can't just call "rand" to get a random port, 'cause then you'll get the same ↵Jim Ingham2011-03-291-0/+7
| | | | | | sequence in two lldb's. This makes running lldb on lldb not work very well. llvm-svn: 128493
* Simple fixes for the gdb remote process plugin on Linux.Stephen Wilson2011-03-252-1/+4
| | | | llvm-svn: 128291
* Fixed the LLDB build so that we can have private types, private enums andGreg Clayton2011-03-244-23/+26
| | | | | | | | public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
* Did a lot more work on abtracting and organizing the platforms. Greg Clayton2011-03-246-51/+321
| | | | | | | | | | | | | | | | | | | | On Mac OS X we now have 3 platforms: PlatformDarwin - must be subclassed to fill in the missing pure virtual funcs but this implements all the common functionality between remote-macosx and remote-ios. It also allows for another platform to be used (remote-gdb-server for now) when doing remote connections. Keeping this pluggable will allow for flexibility. PlatformMacOSX - Now implements both local and remote macosx desktop platforms. PlatformRemoteiOS - Remote only iOS that knows how to locate SDK files in the cached SDK locations on the host. A new agnostic platform has been created: PlatformRemoteGDBServer - this implements the platform using the GDB remote protocol and uses the built in lldb_private::Host static functions to implement many queries. llvm-svn: 128193
* Added new platform commands:Greg Clayton2011-03-235-104/+110
| | | | | | | | | | | | | | | | platform connect <args> platform disconnect Each platform can decide the args they want to use for "platform connect". I will need to add a function that gets the connect options for the current platform as each one can have different options and argument counts. Hooked up more functionality in the PlatformMacOSX and PlatformRemoteiOS. Also started an platform agnostic PlatformRemoteGDBServer.cpp which can end up being used by one or more actual platforms. It can also be specialized and allow for platform specific commands. llvm-svn: 128123
* Split the GDBRemoteCommunication class into three classes:Greg Clayton2011-03-229-1151/+1474
| | | | | | | | | | GDBRemoteCommunication - The base GDB remote communication class GDBRemoteCommunicationClient - designed to be used for clients the connect to a remote GDB server GDBRemoteCommunicationServer - designed to be used on the server side of a GDB server implementation. llvm-svn: 128070
* Added more platform support. There are now some new commands:Greg Clayton2011-03-192-54/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
* Centralize the GDB remote timeout value into the GDBRemoteCommunication as aGreg Clayton2011-03-106-102/+72
| | | | | | | member variable (m_packet_timeout which is a value in seconds). This value is then used for all packets sent to/from the remote GDB server. llvm-svn: 127392
* LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provideGreg Clayton2011-03-082-48/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
* Added a missing API call in SBTarget that enables one to getGreg Clayton2011-03-021-10/+15
| | | | | | | | | | | | anything in a SBSymbolContext filled in given an SBAddress: SBSymbolContext SBTarget::ResolveSymbolContextForAddress (const SBAddress& addr, uint32_t resolve_scope); Also did a little cleanup on the ProcessGDBRemote stdio file handle code. llvm-svn: 126885
* Fixed CommandReturnObject::SetImmediateErrorFile() to set the correct stream.Greg Clayton2011-02-244-346/+382
| | | | | | | | | | | | | | | | | | | | | | | | | Modifed lldb_private::Process to be able to handle connecting to a remote target that isn't running a process. This leaves lldb_private::Process in the eStateConnected state from which we can then do an attach or launch. Modified ProcessGDBRemote to be able to set stdin, stdout, stderr, working dir, disable ASLR and a few other settings down by using new GDB remote packets. This allows us to keep all of our current launch flags and settings intact and still be able to communicate them over to the remote GDB server. Previously these were being sent as arguments to the debugserver binary that we were spawning. Also modified ProcessGDBRemote to handle losing connection to the remote GDB server and always exit immediately. We do this by watching the lldb_private::Communication event bit for the read thread exiting in the ProcessGDBRemote async thread. Added support for many of the new 'Q' packets for setting stdin, stdout, stderr, working dir and disable ASLR to the GDBRemoteCommunication class for easy accesss. Modified debugserver for all of the new 'Q' packets and also made it so that debugserver always exists if it loses connection with the remote debugger. llvm-svn: 126444
* Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified formGreg Clayton2011-02-233-28/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
* The DynamicLoader plug-in instance now lives up in lldb_private::Process whereGreg Clayton2011-02-162-29/+1
| | | | | | | | | | | | | | | | | it should live and the lldb_private::Process takes care of managing the auto pointer to the dynamic loader instance. Also, now that the ArchSpec contains the target triple, we are able to correctly set the Target architecture in DidLaunch/DidAttach in the subclasses, and then the lldb_private::Process will find the dynamic loader plug-in by letting the dynamic loader plug-ins inspect the arch/triple in the target. So now the ProcessGDBRemote plug-in is another step closer to be purely process/platform agnostic. I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly. llvm-svn: 125650
* Fixed an issue where detection of vCont support wasn't being done correctly.Greg Clayton2011-02-161-0/+2
| | | | | | Fixed how the LLDBDisassembler computes and uses a target triple. llvm-svn: 125617
* Made lldb_private::ArchSpec contain much more than just an architecture. ItGreg Clayton2011-02-152-24/+11
| | | | | | | | | | now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
* All UnwindPlan objects are now passed around as shared pointers.Greg Clayton2011-02-155-10/+39
| | | | | | | | | | | | | ArchDefaultUnwindPlan plug-in interfaces are now cached per architecture instead of being leaked for every frame. Split the ArchDefaultUnwindPlan_x86 into ArchDefaultUnwindPlan_x86_64 and ArchDefaultUnwindPlan_i386 interfaces. There were sporadic crashes that were due to something leaking or being destroyed when doing stack crawls. This patch should clear up these issues. llvm-svn: 125541
* Added the ability to detect which vCont packets (using the "vCont?") packetGreg Clayton2011-02-125-123/+458
| | | | | | | | | are supported by the remote GDB target. We can also now deal with the lack of vCont support and send packets that the remote GDB stub can use. We also error out of the continue if LLDB tries to do something too complex when vCont isn't supported. llvm-svn: 125433
* Patch from Kirk Beitz to make things compile on MinGW minus the putenv part.Greg Clayton2011-02-091-1/+1
| | | | llvm-svn: 125199
* Fix comment text.Greg Clayton2011-02-091-1/+1
| | | | llvm-svn: 125162
* <rdar://problem/8972204> Test failure: ./dotest.py -v -t -f ↵Greg Clayton2011-02-091-31/+33
| | | | | | | | UniversalTestCase.test_process_launch_for_universal Fix for bad architecture settings that were being used from the qHostInfo. llvm-svn: 125161
* Rework the RunThreadPlan event handling to use Event Hijacking not stopping ↵Jim Ingham2011-02-081-0/+4
| | | | | | the event thread. Also clarify the logic of the function. llvm-svn: 125083
* Add _pthread_wqthread to the list of thread stop points, and change the ↵Jim Ingham2011-02-081-3/+4
| | | | | | logging a bit. llvm-svn: 125081
* Moved FileSpec into the Host layer since it will vary from host to host.Greg Clayton2011-02-081-1/+1
| | | | | | We have a common unix implementation in lldb/source/Host/common/FileSpec.cpp. llvm-svn: 125078
* Patch that allows for thread_t to be something more complex than anGreg Clayton2011-02-081-3/+3
| | | | | | integer. Modified patch from Kirk Beitz. llvm-svn: 125067
* Apple specific change from Kirk Beitz.Greg Clayton2011-02-051-1/+6
| | | | llvm-svn: 124941
* Added a quicker lookup in the SectionLoadList when looking things up byGreg Clayton2011-02-052-38/+25
| | | | | | | | section by using a DenseMap. Fixed some logging calls to get the log shared pointer. llvm-svn: 124926
* Patch to remove uses of non-standard strcasestr and replace then withGreg Clayton2011-02-041-28/+28
| | | | | | strncasecmp equivalents from Kirk Beitz. llvm-svn: 124889
* Added support for attaching to a remote debug server with the new command:Greg Clayton2011-02-043-22/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (lldb) process connect <remote-url> Currently when you specify a file with the file command it helps us to find a process plug-in that is suitable for debugging. If you specify a file you can rely upon this to find the correct debugger plug-in: % lldb a.out Current executable set to 'a.out' (x86_64). (lldb) process connect connect://localhost:2345 ... If you don't specify a file, you will need to specify the plug-in name that you wish to use: % lldb (lldb) process connect --plugin process.gdb-remote connect://localhost:2345 Other connection URL examples: (lldb) process connect connect://localhost:2345 (lldb) process connect tcp://127.0.0.1 (lldb) process connect file:///dev/ttyS1 We are currently treating the "connect://host:port" as a way to do raw socket connections. If there is a URL for this already, please let me know and we will adopt it. So now you can connect to a remote debug server with the ProcessGDBRemote plug-in. After connection, it will ask for the pid info using the "qC" packet and if it responds with a valid process ID, it will be equivalent to attaching. If it response with an error or invalid process ID, the LLDB process will be in a new state: eStateConnected. This allows us to then download a program or specify the program to run (using the 'A' packet), or specify a process to attach to (using the "vAttach" packets), or query info about the processes that might be available. llvm-svn: 124846
* Fixed the SendInterrupt logic to return the true if the target was haltedGreg Clayton2011-02-031-6/+14
| | | | | | (regardless if the interrupt was sent), and false of not. llvm-svn: 124766
* Endian patch from Kirk Beitz that allows better cross platform building.Greg Clayton2011-02-013-9/+10
| | | | llvm-svn: 124643
* Finished up the async attach support. This allows us to request to attachGreg Clayton2011-01-293-134/+65
| | | | | | | by name or by pid (with or without waiting for a process to launch) and catch the response asynchronously. llvm-svn: 124530
* Fix a little thinko in sending down the thread name to SetName.Jim Ingham2011-01-281-1/+1
| | | | llvm-svn: 124464
* If the user specfies one of stdin, stdout or stderr, don'tCaroline Tice2011-01-281-4/+17
| | | | | | automatically set the non-specified ones to /dev/null. llvm-svn: 124459
* Finally tracked down the racy condition that would hose up our debugGreg Clayton2011-01-271-51/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sessions: When continue packet has been sent and an interrupt packet was quickly sent, it would get read at the same time: $c#00\x03 There was an error where the packet end index was always being computed incorrectly by debugserver, but it wouldn't matter if there weren't extra bytes on the end (the hex \x03 interrupt byte in this case). The first '$' last 3 bytes of the data in the packet buffer were being trimmed (trying to trim the '#' + checksum (#XX)) which made: c# And this would then be passed to the handle routine for the 'c' packet which would see an extra character at the end and assume it was going to be in the form c[addr] where "[addr]" was a hex address to resume at and this would result in a malformed packet response. This is now fixed and everything works great. Another issue was issuing async packets correctly by doing correct handshakes between the thread that wants to send the async packet, and the thread that is tracking the current run. Added a write lock to the communication class as well to make sure you never get two threads trying to write data at the same time. This wasn't happening, but it is a good idea to make sure it doesn't. llvm-svn: 124369
* Enabled extra warnings and fixed a bunch of small issues.Greg Clayton2011-01-252-9/+6
| | | | llvm-svn: 124250
* Reverting recent thread resume changes as it was causing testing issues.Greg Clayton2011-01-251-4/+5
| | | | | | We will need to try again soon, but this change was causing instability. llvm-svn: 124180
* When we are stepping a thread, force it to resume ALL the way to 0. And of ↵Jim Ingham2011-01-251-2/+2
| | | | | | | | course, when we stop if we undid some user provided suspends, we need to re-do the suspends. llvm-svn: 124178
* One more fix to ProcessGDBRemote::DoDestroy(). This one will make sure weGreg Clayton2011-01-251-1/+11
| | | | | | parse the exit status in case we send this packet while stopped. llvm-svn: 124177
* Fixed ProcessGDBRemote to kill the process correctly when it is either runningGreg Clayton2011-01-253-91/+40
| | | | | | | | or stopped. Added support for sections to be able to state if they are encrypted or not. llvm-svn: 124171
* Remember to turn off the debugserver.txt hard-coded emission.Jim Ingham2011-01-241-2/+2
| | | | llvm-svn: 124114
* More useful STEP logging.Jim Ingham2011-01-241-2/+2
| | | | | | Be sure to clear out the base plan's m_report_run and m_report_stop each time we resume so we don't use stale values. llvm-svn: 124113
* Improved process logging for both lldb_private::Process and ProcessGDBRemote.Greg Clayton2011-01-231-10/+43
| | | | llvm-svn: 124080
* Added a new variant of SBTarget::Launch() that deprectates the old one thatGreg Clayton2011-01-232-13/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | takes separate file handles for stdin, stdout, and stder and also allows for the working directory to be specified. Added support to "process launch" to a new option: --working-dir=PATH. We can now set the working directory. If this is not set, it defaults to that of the process that has LLDB loaded. Added the working directory to the host LaunchInNewTerminal function to allows the current working directory to be set in processes that are spawned in their own terminal. Also hooked this up to the lldb_private::Process and all mac plug-ins. The linux plug-in had its API changed, but nothing is making use of it yet. Modfied "debugserver" and "darwin-debug" to also handle the current working directory options and modified the code in LLDB that spawns these tools to pass the info along. Fixed ProcessGDBRemote to properly pass along all file handles for stdin, stdout and stderr. After clearing the default values for the stdin/out/err file handles for process to be NULL, we had a crasher in UserSettingsController::UpdateStringVariable which is now fixed. Also fixed the setting of boolean values to be able to be set as "true", "yes", "on", "1" for true (case insensitive) and "false", "no", "off", or "0" for false. Fixed debugserver to properly handle files for STDIN, STDOUT and STDERR that are not already opened. Previous to this fix debugserver would only correctly open and dupe file handles for the slave side of a pseudo terminal. It now correctly handles getting STDIN for the inferior from a file, and spitting STDOUT and STDERR out to files. Also made sure the file handles were correctly opened with the NOCTTY flag for terminals. llvm-svn: 124060
* Fixed an issue in "SBError SBProcess::Destroy ()" where it wasn't properlyGreg Clayton2011-01-224-30/+131
| | | | | | | | | | | | | | | | | | | | checking the validity of the shared pointer prior to using it. Fixed the GDB remote plug-in to once again watch for a reply from the "k" packet, and fixed the logic to make sure the thread requesting the kill and the async thread play nice (and very quickly) by synchronizing the packet sending and reply. I also tweaked some of the shut down packet ("k" kill, "D" detach, and the halt packet) to make sure they do the right thing. Fixed "StateType Process::WaitForProcessStopPrivate (...)" to correctly pass the timeout along to WaitForStateChangedEventsPrivate() and made the function behave correctly with respect to timing out. Added separate STDIN, STDOUT, and STDERR support to debugserver. Also added the start of being able to set the working directory for the inferior process. llvm-svn: 124049
* Sped up the shutdown time on MacOSX by quite a bit by making sure anyGreg Clayton2011-01-223-46/+50
| | | | | | | | | | | | | | | | | threads that we spawn let us know when they are going away and that we don't timeout waiting for a message from threads that have gone away. We also now don't expect the "k" packet (kill) to send a response. This greatly speeds up debugger shutdown performance. The test suite now runs quite a bit faster. Added a fix to the variable display code that fixes the display of base classes. We were assuming the virtual or normal base class offsets were being given in bit sizes, but they were being given as character sizes, so we needed to multiply the offset by 8. This wasn't affecting the expression parser, but it was affecting the correct display of C++ class base classes and all of their children. llvm-svn: 124024
* Added an interface for noticing new thread creation. At this point, I only ↵Jim Ingham2011-01-222-1/+103
| | | | | | | | | | turn it on when we are requesting a single thread to run. May seem like a silly thing to do, but the kernel on MacOS X will inject new threads into a program willy-nilly, and I would like to keep them from running if I can. llvm-svn: 124018
* Fixed the async packets (packets that need to be sent to the GDB server Greg Clayton2011-01-202-8/+25
| | | | | | | | | | | while the inferior is running) to be fast. The previous code would always cause the sender to timeout, yet still return success due to the way we were waiting for a value (incorrect value) to change. Now the ProcessGDBRemote plug-in has a public and private "is running" predicate. This allows things that need to send async packets to interrupt and wait for the private "is running" state to be flipped to false, and then resume quickly with no timeout. llvm-svn: 123903
* Back up both the register AND the stop state when calling functions.Jim Ingham2011-01-202-15/+7
| | | | | | | Set the thread state to "bland" before calling functions so they don't inherit the pending signals and die. llvm-svn: 123869
* Thread safety changes in debugserver and also in the process GDB remote plugin.Greg Clayton2011-01-184-14/+65
| | | | | | | | | | | | | | I added support for asking if the GDB remote server supports thread suffixes for packets that should be thread specific (register read/write packets) because the way the GDB remote protocol does it right now is to have a notion of a current thread for register and memory reads/writes (set via the "$Hg%x" packet) and a current thread for running ("$Hc%x"). Now we ask the remote GDB server if it supports adding the thread ID to the register packets and we enable that feature in LLDB if supported. This stops us from having to send a bunch of packets that update the current thread ID to some value which is prone to error, or extra packets. llvm-svn: 123762
OpenPOWER on IntegriCloud