summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote
Commit message (Collapse)AuthorAgeFilesLines
...
* Add support for the 'G' packet not being implemented or returning an error.Greg Clayton2011-05-162-7/+44
| | | | | | | If we are asked to restore all register values, we need to fall back to restoring each register one by one. llvm-svn: 131398
* Fixed an issue where large memory writes might not get chunked up into smallerGreg Clayton2011-05-161-0/+8
| | | | | | | | packets in GDB remote. Also fixed a compiler warning for an unhandled case for a switch. llvm-svn: 131397
* Dump JIT memory requirements when "log enable lldb expr" logging is enabled.Greg Clayton2011-05-151-1/+7
| | | | | | Correctly handle invalid 32-bit mmap fail return value in ProcessGDBRemote. llvm-svn: 131394
* Properly handle when commands are not unsupported in the GDB remote clients.Greg Clayton2011-05-151-55/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this fix we would often call SendPacketAndWaitForResponse() which returns the number of bytes in the response. The UNSUPPORTED response in the GDB remote protocol is zero bytes and we were checking for it inside an if statement: if (SendPacketAndWaitForResponse(...)) { if (response.IsUnsupportedResponse()) { // UNSUPPORTED... // This will never happen... } } We now handle is properly as: if (SendPacketAndWaitForResponse(...)) { } else { // UNSUPPORTED... } llvm-svn: 131393
* Fixed the default ARM registers to have the generic argumentGreg Clayton2011-05-151-5/+5
| | | | | | definitions and names. llvm-svn: 131387
* Added the ability to get the return value from a ThreadPlanCallFunctionGreg Clayton2011-05-155-47/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | thread plan. In order to get the return value, you can call: void ThreadPlanCallFunction::RequestReturnValue (lldb::ValueSP &return_value_sp); This registers a shared pointer to a return value that will get filled in if everything goes well. After the thread plan is run the return value will be extracted for you. Added an ifdef to be able to switch between the LLVM MCJIT and the standand JIT. We currently have the standard JIT selected because we have some work to do to get the MCJIT fuctioning properly. Added the ability to call functions with 6 argument in the x86_64 ABI. Added the ability for GDBRemoteCommunicationClient to detect if the allocate and deallocate memory packets are supported and to not call allocate memory ("_M") or deallocate ("_m") if we find they aren't supported. Modified the ProcessGDBRemote::DoAllocateMemory(...) and ProcessGDBRemote::DoDeallocateMemory(...) to be able to deal with the allocate and deallocate memory packets not being supported. If they are not supported, ProcessGDBRemote will switch to calling "mmap" and "munmap" to allocate and deallocate memory instead using our trivial function call support. Modified the "void ProcessGDBRemote::DidLaunchOrAttach()" to correctly ignore the qHostInfo triple information if any was specified in the target. Currently if the target only specifies an architecture when creating the target: (lldb) target create --arch i386 a.out Then the vendor, os and environemnt will be adopted by the target. If the target was created with any triple that specifies more than the arch: (lldb) target create --arch i386-unknown-unknown a.out Then the target will maintain its triple and not adopt any new values. This can be used to help force bare board debugging where the dynamic loader for static files will get used and users can then use "target modules load ..." to set addressses for any files that are desired. Added back some convenience functions to the lldb_private::RegisterContext class for writing registers with unsigned values. Also made all RegisterContext constructors explicit to make sure we know when an integer is being converted to a RegisterValue. llvm-svn: 131370
* Expand the ABI prepare trivial function call to allow 6 simple args.Greg Clayton2011-05-143-19/+140
| | | | llvm-svn: 131334
* PATH_MAX is in limits.h on Linux.Johnny Chen2011-05-131-0/+1
| | | | | | Patch by Marco Minutoli <mminutoli@gmail.com> llvm-svn: 131304
* Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into theirGreg Clayton2011-05-111-2/+2
| | | | | | | | | | | | | | | respective ABI plugins as they were plug-ins that supplied ABI specfic info. Also hookep up the UnwindAssemblyInstEmulation so that it can generate the unwind plans for ARM. Changed the way ABI plug-ins are handed out when you get an instance from the plug-in manager. They used to return pointers that would be mananged individually by each client that requested them, but now they are handed out as shared pointers since there is no state in the ABI objects, they can be shared. llvm-svn: 131193
* While implementing unwind information using UnwindAssemblyInstEmulation I ranGreg Clayton2011-05-092-103/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into some cleanup I have been wanting to do when reading/writing registers. Previously all RegisterContext subclasses would need to implement: virtual bool ReadRegisterBytes (uint32_t reg, DataExtractor &data); virtual bool WriteRegisterBytes (uint32_t reg, DataExtractor &data, uint32_t data_offset = 0); There is now a new class specifically designed to hold register values: lldb_private::RegisterValue The new register context calls that subclasses must implement are: virtual bool ReadRegister (const RegisterInfo *reg_info, RegisterValue &reg_value) = 0; virtual bool WriteRegister (const RegisterInfo *reg_info, const RegisterValue &reg_value) = 0; The RegisterValue class must be big enough to handle any register value. The class contains an enumeration for the value type, and then a union for the data value. Any integer/float values are stored directly in an appropriate host integer/float. Anything bigger is stored in a byte buffer that has a length and byte order. The RegisterValue class also knows how to copy register value bytes into in a buffer with a specified byte order which can be used to write the register value down into memory, and this does the right thing when not all bytes from the register values are needed (getting a uint8 from a uint32 register value..). All RegiterContext and other sources have been switched over to using the new regiter value class. llvm-svn: 131096
* Fixed not being able to launch the i386 slice of a universal binary by addingGreg Clayton2011-05-083-0/+23
| | | | | | | | a new "QLaunchArch:<arch-name>" where <arch-name> is the architecture name. This allows us to remotely launch a debugserver and then set the architecture for the binary we will launch. llvm-svn: 131064
* Added the ability to set the Platform path for a module through the SBModuleGreg Clayton2011-04-301-8/+1
| | | | | | | | | | | | | | interface. Added a quick way to set the platform though the SBDebugger interface. I will actually an a SBPlatform support soon, but for now this will do. ConnectionFileDescriptor can be passed a url formatted as: "fd://<fd>" where <fd> is a file descriptor in the current process. This is handy if you have services, deamons, or other tools that can spawn processes and give you a file handle. llvm-svn: 130565
* Got the EmulateInstruction CFI code a lot closer to producing CFI data.Greg Clayton2011-04-261-2/+2
| | | | | | | | | | | | | Switch the EmulateInstruction to use the standard RegisterInfo structure that is defined in the lldb private types intead of passing the reg kind and reg num everywhere. EmulateInstruction subclasses also need to provide RegisterInfo structs given a reg kind and reg num. This eliminates the need for the GetRegisterName() virtual function and allows more complete information to be passed around in the read/write register callbacks. Subclasses should always provide RegiterInfo structs with the generic register info filled in as well as at least one kind of register number in the RegisterInfo.kinds[] array. llvm-svn: 130256
* Changed the emulate instruction function to take emulate options whichGreg Clayton2011-04-261-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | are defined as enumerations. Current bits include: eEmulateInstructionOptionAutoAdvancePC eEmulateInstructionOptionIgnoreConditions Modified the EmulateInstruction class to have a few more pure virtuals that can help clients understand how many instructions the emulator can handle: virtual bool SupportsEmulatingIntructionsOfType (InstructionType inst_type) = 0; Where instruction types are defined as: //------------------------------------------------------------------ /// Instruction types //------------------------------------------------------------------ typedef enum InstructionType { eInstructionTypeAny, // Support for any instructions at all (at least one) eInstructionTypePrologueEpilogue, // All prologue and epilogue instructons that push and pop register values and modify sp/fp eInstructionTypePCModifying, // Any instruction that modifies the program counter/instruction pointer eInstructionTypeAll // All instructions of any kind } InstructionType; This allows use to tell what an emulator can do and also allows us to request these abilities when we are finding the plug-in interface. Added the ability for an EmulateInstruction class to get the register names for any registers that are part of the emulation. This helps with being able to dump and log effectively. The UnwindAssembly class now stores the architecture it was created with in case it is needed later in the unwinding process. Added a function that can tell us DWARF register names for ARM that goes along with the source/Utility/ARM_DWARF_Registers.h file: source/Utility/ARM_DWARF_Registers.c Took some of plug-ins out of the lldb_private namespace. llvm-svn: 130189
* Moved the execution context that was in the Debugger intoGreg Clayton2011-04-1210-417/+1034
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
* Modified the ArchSpec to take an optional "Platform *" when setting the triple.Greg Clayton2011-04-072-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | This allows you to have a platform selected, then specify a triple using "i386" and have the remaining triple items (vendor, os, and environment) set automatically. Many interpreter commands take the "--arch" option to specify an architecture triple, so now the command options needed to be able to get to the current platform, so the Options class now take a reference to the interpreter on construction. Modified the build LLVM building in the Xcode project to use the new Xcode project level user definitions: LLVM_BUILD_DIR - a path to the llvm build directory LLVM_SOURCE_DIR - a path to the llvm sources for the llvm that will be used to build lldb LLVM_CONFIGURATION - the configuration that lldb is built for (Release, Release+Asserts, Debug, Debug+Asserts). I also changed the LLVM build to not check if "lldb/llvm" is a symlink and then assume it is a real llvm build directory versus the unzipped llvm.zip package, so now you can actually have a "lldb/llvm" directory in your lldb sources. llvm-svn: 129112
* Removed use of NSEC_PER_SEC.Stephen Wilson2011-04-071-6/+6
| | | | | | | | | NSEC_PER_SEC is not defined in sys/time.h on Linux. Replaced that macro with a static constant inside TimeValue. Patch by Marco Minutoli. llvm-svn: 129071
* Added a speed test to the GDBRemoteCommunicationClient and Greg Clayton2011-04-044-3/+137
| | | | | | | | | | | | | GDBRemoteCommunicationServer classes. This involved adding a new packet named "qSpeedTest" which can test the speed of a packet send/response pairs using a wide variety of send/recv packet sizes. Added a few new connection classes: one for shared memory, and one for using mach messages (Apple only). The mach message stuff is experimental and not working yet, but added so I don't lose the code. The shared memory stuff uses pretty standard calls to setup shared memory. llvm-svn: 128837
* Added the ability to get a broadcaster event name for a given broadcasterGreg Clayton2011-04-012-1/+3
| | | | | | | | | | | | | | event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
* Many improvements to the Platform base class and subclasses. The base PlatformGreg Clayton2011-03-308-185/+745
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | class now implements the Host functionality for a lot of things that make sense by default so that subclasses can check: int PlatformSubclass::Foo () { if (IsHost()) return Platform::Foo (); // Let the platform base class do the host specific stuff // Platform subclass specific code... int result = ... return result; } Added new functions to the platform: virtual const char *Platform::GetUserName (uint32_t uid); virtual const char *Platform::GetGroupName (uint32_t gid); The user and group names are cached locally so that remote platforms can avoid sending packets multiple times to resolve this information. Added the parent process ID to the ProcessInfo class. Added a new ProcessInfoMatch class which helps us to match processes up and changed the Host layer over to using this new class. The new class allows us to search for processs: 1 - by name (equal to, starts with, ends with, contains, and regex) 2 - by pid 3 - And further check for parent pid == value, uid == value, gid == value, euid == value, egid == value, arch == value, parent == value. This is all hookup up to the "platform process list" command which required adding dumping routines to dump process information. If the Host class implements the process lookup routines, you can now lists processes on your local machine: machine1.foo.com % lldb (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari 94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode 92742 92710 username usergroup username usergroup i386-apple-darwin debugserver This of course also works remotely with the lldb-platform: machine1.foo.com % lldb-platform --listen 1234 machine2.foo.com % lldb (lldb) platform create remote-macosx Platform: remote-macosx Connected: no (lldb) platform connect connect://localhost:1444 Platform: remote-macosx Triple: x86_64-apple-darwin OS Version: 10.6.7 (10J869) Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 Hostname: machine1.foo.com Connected: yes (lldb) platform process list PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME ====== ====== ========== ========== ========== ========== ======================== ============================ 99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation 99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb 99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge 94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker 94852 244 username usergroup username usergroup x86_64-apple-darwin Safari The lldb-platform implements everything with the Host:: layer, so this should "just work" for linux. I will probably be adding more stuff to the Host layer for launching processes and attaching to processes so that this support should eventually just work as well. Modified the target to be able to be created with an architecture that differs from the main executable. This is needed for iOS debugging since we can have an "armv6" binary which can run on an "armv7" machine, so we want to be able to do: % lldb (lldb) platform create remote-ios (lldb) file --arch armv7 a.out Where "a.out" is an armv6 executable. The platform then can correctly decide to open all "armv7" images for all dependent shared libraries. Modified the disassembly to show the current PC value. Example output: (lldb) disassemble --frame a.out`main: 0x1eb7: pushl %ebp 0x1eb8: movl %esp, %ebp 0x1eba: pushl %ebx 0x1ebb: subl $20, %esp 0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18 0x1ec3: popl %ebx -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf 0x1edb: leal 213(%ebx), %eax 0x1ee1: movl %eax, (%esp) 0x1ee4: calll 0x1f1e ; puts 0x1ee9: calll 0x1f0c ; getchar 0x1eee: movl $20, (%esp) 0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6 0x1efa: movl $12, %eax 0x1eff: addl $20, %esp 0x1f02: popl %ebx 0x1f03: leave 0x1f04: ret This can be handy when dealing with the new --line options that was recently added: (lldb) disassemble --line a.out`main + 13 at test.c:19 18 { -> 19 printf("Process: %i\n\n", getpid()); 20 puts("Press any key to continue..."); getchar(); -> 0x1ec4: calll 0x1f12 ; getpid 0x1ec9: movl %eax, 4(%esp) 0x1ecd: leal 199(%ebx), %eax 0x1ed3: movl %eax, (%esp) 0x1ed6: calll 0x1f18 ; printf Modified the ModuleList to have a lookup based solely on a UUID. Since the UUID is typically the MD5 checksum of a binary image, there is no need to give the path and architecture when searching for a pre-existing image in an image list. Now that we support remote debugging a bit better, our lldb_private::Module needs to be able to track what the original path for file was as the platform knows it, as well as where the file is locally. The module has the two following functions to retrieve both paths: const FileSpec &Module::GetFileSpec () const; const FileSpec &Module::GetPlatformFileSpec () const; llvm-svn: 128563
* 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
OpenPOWER on IntegriCloud