maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/Utility/StringExtractorGDBRemote.cpp

394 lines
14 KiB
C++
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//===-- StringExtractorGDBRemote.cpp ----------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
// C Includes
Add a missing include needed on Linux and remove a trailing comma. llvm-svn: 128134
2011-03-23 10:02:29 +08:00
#include <string.h>
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// C++ Includes
// Other libraries and framework includes
// Project includes
Add a missing include needed on Linux and remove a trailing comma. llvm-svn: 128134
2011-03-23 10:02:29 +08:00
#include "Utility/StringExtractorGDBRemote.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
StringExtractorGDBRemote::ResponseType
StringExtractorGDBRemote::GetResponseType () const
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
if (m_packet.empty())
return eUnsupported;
switch (m_packet[0])
{
case 'E':
if (m_packet.size() == 3 &&
isxdigit(m_packet[1]) &&
isxdigit(m_packet[2]))
return eError;
break;
case 'O':
if (m_packet.size() == 2 && m_packet[1] == 'K')
return eOK;
break;
case '+':
if (m_packet.size() == 1)
return eAck;
break;
case '-':
if (m_packet.size() == 1)
return eNack;
break;
}
return eResponse;
}
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
StringExtractorGDBRemote::ServerPacketType
StringExtractorGDBRemote::GetServerPacketType () const
{
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
#define PACKET_MATCHES(s) ((packet_size == (sizeof(s)-1)) && (strcmp((packet_cstr),(s)) == 0))
#define PACKET_STARTS_WITH(s) ((packet_size >= (sizeof(s)-1)) && ::strncmp(packet_cstr, s, (sizeof(s)-1))==0)
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
// Empty is not a supported packet...
if (m_packet.empty())
return eServerPacketType_invalid;
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
const size_t packet_size = m_packet.size();
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
const char *packet_cstr = m_packet.c_str();
switch (m_packet[0])
{
Remote Non-Stop Support Summary: This patch is the beginnings of support for Non-stop mode in the remote protocol. Letting a user examine stopped threads, while other threads execute freely. Non-stop mode is enabled using the setting target.non-stop-mode, which sends a QNonStop packet when establishing the remote connection. Changes are also made to treat the '?' stop reply packet differently in non-stop mode, according to spec https://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop. A setting for querying the remote for default thread on setup is also included. Handling of '%' async notification packets will be added next. Reviewers: clayborg Subscribers: lldb-commits, ADodds, ted, deepak2427 Differential Revision: http://reviews.llvm.org/D9656 llvm-svn: 237239
2015-05-13 17:18:18 +08:00
case '%':
return eServerPacketType_notify;
Added new platform commands: 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
2011-03-23 08:09:55 +08:00
case '\x03':
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
if (packet_size == 1) return eServerPacketType_interrupt;
Added new platform commands: 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
2011-03-23 08:09:55 +08:00
break;
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
case '-':
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
if (packet_size == 1) return eServerPacketType_nack;
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
break;
case '+':
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
if (packet_size == 1) return eServerPacketType_ack;
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
break;
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
case 'A':
return eServerPacketType_A;
Refactor Unix signals. Summary: - Consolidate Unix signals selection in UnixSignals. - Make Unix signals available from platform. - Add jSignalsInfo packet to retrieve Unix signals from remote platform. - Get a copy of the platform signal for each remote process. - Update SB API for signals. - Update signal utility in test suite. Reviewers: ovyalov, clayborg Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11094 llvm-svn: 242101
2015-07-14 09:09:28 +08:00
Did a lot more work on abtracting and organizing the platforms. 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
2011-03-24 12:28:38 +08:00
case 'Q':
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
switch (packet_cstr[1])
{
case 'E':
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
if (PACKET_STARTS_WITH ("QEnvironment:")) return eServerPacketType_QEnvironment;
if (PACKET_STARTS_WITH ("QEnvironmentHexEncoded:")) return eServerPacketType_QEnvironmentHexEncoded;
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
break;
case 'S':
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
if (PACKET_MATCHES ("QStartNoAckMode")) return eServerPacketType_QStartNoAckMode;
if (PACKET_STARTS_WITH ("QSaveRegisterState")) return eServerPacketType_QSaveRegisterState;
if (PACKET_STARTS_WITH ("QSetDisableASLR:")) return eServerPacketType_QSetDisableASLR;
Added an option to turn OFF the "detach on error" behavior that was added to debugserver when launching processes. <rdar://problem/16216199> llvm-svn: 211658
2014-06-25 10:32:56 +08:00
if (PACKET_STARTS_WITH ("QSetDetachOnError:")) return eServerPacketType_QSetDetachOnError;
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
if (PACKET_STARTS_WITH ("QSetSTDIN:")) return eServerPacketType_QSetSTDIN;
if (PACKET_STARTS_WITH ("QSetSTDOUT:")) return eServerPacketType_QSetSTDOUT;
if (PACKET_STARTS_WITH ("QSetSTDERR:")) return eServerPacketType_QSetSTDERR;
if (PACKET_STARTS_WITH ("QSetWorkingDir:")) return eServerPacketType_QSetWorkingDir;
if (PACKET_STARTS_WITH ("QSetLogging:")) return eServerPacketType_QSetLogging;
if (PACKET_STARTS_WITH ("QSetMaxPacketSize:")) return eServerPacketType_QSetMaxPacketSize;
if (PACKET_STARTS_WITH ("QSetMaxPayloadSize:")) return eServerPacketType_QSetMaxPayloadSize;
if (PACKET_STARTS_WITH ("QSetEnableAsyncProfiling;")) return eServerPacketType_QSetEnableAsyncProfiling;
if (PACKET_STARTS_WITH ("QSyncThreadState:")) return eServerPacketType_QSyncThreadState;
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
break;
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
merge lldb-platform-work branch (and assorted fixes) into trunk Summary: This merge brings in the improved 'platform' command that knows how to interface with remote machines; that is, query OS/kernel information, push and pull files, run shell commands, etc... and implementation for the new communication packets that back that interface, at least on Darwin based operating systems via the POSIXPlatform class. Linux support is coming soon. Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS X Mountain Lion. Additional improvements (not in the source SVN branch 'lldb-platform-work'): - cmake build scripts for lldb-platform - cleanup test suite - documentation stub for qPlatform_RunCommand - use log class instead of printf() directly - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely. - add new logging category 'platform' Reviewers: Matt Kopec, Greg Clayton Review: http://llvm-reviews.chandlerc.com/D1493 llvm-svn: 189295
2013-08-27 07:57:52 +08:00
case 'L':
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
if (PACKET_STARTS_WITH ("QLaunchArch:")) return eServerPacketType_QLaunchArch;
if (PACKET_MATCHES("QListThreadsInStopReply")) return eServerPacketType_QListThreadsInStopReply;
break;
case 'R':
if (PACKET_STARTS_WITH ("QRestoreRegisterState:")) return eServerPacketType_QRestoreRegisterState;
break;
case 'T':
if (PACKET_MATCHES ("QThreadSuffixSupported")) return eServerPacketType_QThreadSuffixSupported;
merge lldb-platform-work branch (and assorted fixes) into trunk Summary: This merge brings in the improved 'platform' command that knows how to interface with remote machines; that is, query OS/kernel information, push and pull files, run shell commands, etc... and implementation for the new communication packets that back that interface, at least on Darwin based operating systems via the POSIXPlatform class. Linux support is coming soon. Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS X Mountain Lion. Additional improvements (not in the source SVN branch 'lldb-platform-work'): - cmake build scripts for lldb-platform - cleanup test suite - documentation stub for qPlatform_RunCommand - use log class instead of printf() directly - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely. - add new logging category 'platform' Reviewers: Matt Kopec, Greg Clayton Review: http://llvm-reviews.chandlerc.com/D1493 llvm-svn: 189295
2013-08-27 07:57:52 +08:00
break;
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
}
Did a lot more work on abtracting and organizing the platforms. 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
2011-03-24 12:28:38 +08:00
break;
Refactor Unix signals. Summary: - Consolidate Unix signals selection in UnixSignals. - Make Unix signals available from platform. - Add jSignalsInfo packet to retrieve Unix signals from remote platform. - Get a copy of the platform signal for each remote process. - Update SB API for signals. - Update signal utility in test suite. Reviewers: ovyalov, clayborg Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11094 llvm-svn: 242101
2015-07-14 09:09:28 +08:00
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
case 'q':
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
switch (packet_cstr[1])
{
case 's':
if (PACKET_MATCHES ("qsProcessInfo")) return eServerPacketType_qsProcessInfo;
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
if (PACKET_MATCHES ("qsThreadInfo")) return eServerPacketType_qsThreadInfo;
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
break;
case 'f':
if (PACKET_STARTS_WITH ("qfProcessInfo")) return eServerPacketType_qfProcessInfo;
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
if (PACKET_STARTS_WITH ("qfThreadInfo")) return eServerPacketType_qfThreadInfo;
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
break;
case 'C':
if (packet_size == 2) return eServerPacketType_qC;
break;
Add support for the qEcho command to lldb-server in the common packets. llvm-svn: 238533
2015-05-29 08:15:15 +08:00
case 'E':
if (PACKET_STARTS_WITH ("qEcho:")) return eServerPacketType_qEcho;
break;
Fetch object file load address if it isn't specified by the linker Differential revision: http://reviews.llvm.org/D10490 llvm-svn: 240052
2015-06-19 04:43:56 +08:00
case 'F':
if (PACKET_STARTS_WITH ("qFileLoadAddress:")) return eServerPacketType_qFileLoadAddress;
break;
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
case 'G':
if (PACKET_STARTS_WITH ("qGroupName:")) return eServerPacketType_qGroupName;
Expose SBPlatform through the public API. Example code: remote_platform = lldb.SBPlatform("remote-macosx"); remote_platform.SetWorkingDirectory("/private/tmp") debugger.SetSelectedPlatform(remote_platform) connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111"); err = remote_platform.ConnectRemote(connect_options) if err.Success(): print >> result, 'Connected to remote platform:' print >> result, 'hostname: %s' % (remote_platform.GetHostname()) src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False) dst = lldb.SBFileSpec() # copy src to platform working directory since "dst" is empty err = remote_platform.Install(src, dst); if err.Success(): print >> result, '%s installed successfully' % (src) else: print >> result, 'error: failed to install "%s": %s' % (src, err) Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories. The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform. The API in SBPlatform is subject to change and will be getting many new functions. llvm-svn: 195273
2013-11-21 05:07:01 +08:00
if (PACKET_MATCHES ("qGetWorkingDir")) return eServerPacketType_qGetWorkingDir;
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
if (PACKET_MATCHES ("qGetPid")) return eServerPacketType_qGetPid;
if (PACKET_STARTS_WITH ("qGetProfileData;")) return eServerPacketType_qGetProfileData;
if (PACKET_MATCHES ("qGDBServerVersion")) return eServerPacketType_qGDBServerVersion;
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
break;
case 'H':
if (PACKET_MATCHES ("qHostInfo")) return eServerPacketType_qHostInfo;
break;
merge lldb-platform-work branch (and assorted fixes) into trunk Summary: This merge brings in the improved 'platform' command that knows how to interface with remote machines; that is, query OS/kernel information, push and pull files, run shell commands, etc... and implementation for the new communication packets that back that interface, at least on Darwin based operating systems via the POSIXPlatform class. Linux support is coming soon. Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS X Mountain Lion. Additional improvements (not in the source SVN branch 'lldb-platform-work'): - cmake build scripts for lldb-platform - cleanup test suite - documentation stub for qPlatform_RunCommand - use log class instead of printf() directly - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely. - add new logging category 'platform' Reviewers: Matt Kopec, Greg Clayton Review: http://llvm-reviews.chandlerc.com/D1493 llvm-svn: 189295
2013-08-27 07:57:52 +08:00
case 'K':
if (PACKET_STARTS_WITH ("qKillSpawnedProcess")) return eServerPacketType_qKillSpawnedProcess;
break;
Modify "platform connect" to connect to processes as well The standard remote debugging workflow with gdb is to start the application on the remote host under gdbserver (e.g.: gdbserver :5039 a.out) and then connect to it with gdb. The same workflow is supported by debugserver/lldb-gdbserver with a very similar syntax but to access all features of lldb we need to be connected also to an lldb-platform instance running on the target. Before this change this had to be done manually with starting a separate lldb-platform on the target machine and then connecting to it with lldb before connecting to the process. This change modifies the behavior of "platform connect" with automatically connecting to the process instance if it was started by the remote platform. With this command replacing gdbserver in a gdb based worflow is usually as simple as replacing the command to execute gdbserver with executing lldb-platform. Differential revision: http://reviews.llvm.org/D14952 llvm-svn: 255016
2015-12-08 22:08:19 +08:00
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
case 'L':
merge lldb-platform-work branch (and assorted fixes) into trunk Summary: This merge brings in the improved 'platform' command that knows how to interface with remote machines; that is, query OS/kernel information, push and pull files, run shell commands, etc... and implementation for the new communication packets that back that interface, at least on Darwin based operating systems via the POSIXPlatform class. Linux support is coming soon. Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS X Mountain Lion. Additional improvements (not in the source SVN branch 'lldb-platform-work'): - cmake build scripts for lldb-platform - cleanup test suite - documentation stub for qPlatform_RunCommand - use log class instead of printf() directly - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely. - add new logging category 'platform' Reviewers: Matt Kopec, Greg Clayton Review: http://llvm-reviews.chandlerc.com/D1493 llvm-svn: 189295
2013-08-27 07:57:52 +08:00
if (PACKET_STARTS_WITH ("qLaunchGDBServer")) return eServerPacketType_qLaunchGDBServer;
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
if (PACKET_MATCHES ("qLaunchSuccess")) return eServerPacketType_qLaunchSuccess;
break;
Modify "platform connect" to connect to processes as well The standard remote debugging workflow with gdb is to start the application on the remote host under gdbserver (e.g.: gdbserver :5039 a.out) and then connect to it with gdb. The same workflow is supported by debugserver/lldb-gdbserver with a very similar syntax but to access all features of lldb we need to be connected also to an lldb-platform instance running on the target. Before this change this had to be done manually with starting a separate lldb-platform on the target machine and then connecting to it with lldb before connecting to the process. This change modifies the behavior of "platform connect" with automatically connecting to the process instance if it was started by the remote platform. With this command replacing gdbserver in a gdb based worflow is usually as simple as replacing the command to execute gdbserver with executing lldb-platform. Differential revision: http://reviews.llvm.org/D14952 llvm-svn: 255016
2015-12-08 22:08:19 +08:00
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
case 'M':
if (PACKET_STARTS_WITH ("qMemoryRegionInfo:")) return eServerPacketType_qMemoryRegionInfo;
if (PACKET_MATCHES ("qMemoryRegionInfo")) return eServerPacketType_qMemoryRegionInfoSupported;
Add qModuleInfo request in order to get module information (uuid, triple,..) by module path from remote platform. http://reviews.llvm.org/D7709 llvm-svn: 230556
2015-02-26 06:15:44 +08:00
if (PACKET_STARTS_WITH ("qModuleInfo:")) return eServerPacketType_qModuleInfo;
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
break;
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
case 'P':
Expose SBPlatform through the public API. Example code: remote_platform = lldb.SBPlatform("remote-macosx"); remote_platform.SetWorkingDirectory("/private/tmp") debugger.SetSelectedPlatform(remote_platform) connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111"); err = remote_platform.ConnectRemote(connect_options) if err.Success(): print >> result, 'Connected to remote platform:' print >> result, 'hostname: %s' % (remote_platform.GetHostname()) src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False) dst = lldb.SBFileSpec() # copy src to platform working directory since "dst" is empty err = remote_platform.Install(src, dst); if err.Success(): print >> result, '%s installed successfully' % (src) else: print >> result, 'error: failed to install "%s": %s' % (src, err) Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories. The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform. The API in SBPlatform is subject to change and will be getting many new functions. llvm-svn: 195273
2013-11-21 05:07:01 +08:00
if (PACKET_STARTS_WITH ("qProcessInfoPID:")) return eServerPacketType_qProcessInfoPID;
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
if (PACKET_STARTS_WITH ("qPlatform_shell:")) return eServerPacketType_qPlatform_shell;
Expose SBPlatform through the public API. Example code: remote_platform = lldb.SBPlatform("remote-macosx"); remote_platform.SetWorkingDirectory("/private/tmp") debugger.SetSelectedPlatform(remote_platform) connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111"); err = remote_platform.ConnectRemote(connect_options) if err.Success(): print >> result, 'Connected to remote platform:' print >> result, 'hostname: %s' % (remote_platform.GetHostname()) src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False) dst = lldb.SBFileSpec() # copy src to platform working directory since "dst" is empty err = remote_platform.Install(src, dst); if err.Success(): print >> result, '%s installed successfully' % (src) else: print >> result, 'error: failed to install "%s": %s' % (src, err) Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories. The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform. The API in SBPlatform is subject to change and will be getting many new functions. llvm-svn: 195273
2013-11-21 05:07:01 +08:00
if (PACKET_STARTS_WITH ("qPlatform_mkdir:")) return eServerPacketType_qPlatform_mkdir;
if (PACKET_STARTS_WITH ("qPlatform_chmod:")) return eServerPacketType_qPlatform_chmod;
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
if (PACKET_MATCHES ("qProcessInfo")) return eServerPacketType_qProcessInfo;
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
break;
Modify "platform connect" to connect to processes as well The standard remote debugging workflow with gdb is to start the application on the remote host under gdbserver (e.g.: gdbserver :5039 a.out) and then connect to it with gdb. The same workflow is supported by debugserver/lldb-gdbserver with a very similar syntax but to access all features of lldb we need to be connected also to an lldb-platform instance running on the target. Before this change this had to be done manually with starting a separate lldb-platform on the target machine and then connecting to it with lldb before connecting to the process. This change modifies the behavior of "platform connect" with automatically connecting to the process instance if it was started by the remote platform. With this command replacing gdbserver in a gdb based worflow is usually as simple as replacing the command to execute gdbserver with executing lldb-platform. Differential revision: http://reviews.llvm.org/D14952 llvm-svn: 255016
2015-12-08 22:08:19 +08:00
case 'Q':
if (PACKET_MATCHES ("qQueryGDBServer")) return eServerPacketType_qQueryGDBServer;
break;
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
case 'R':
if (PACKET_STARTS_WITH ("qRcmd,")) return eServerPacketType_qRcmd;
if (PACKET_STARTS_WITH ("qRegisterInfo")) return eServerPacketType_qRegisterInfo;
break;
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
case 'S':
if (PACKET_STARTS_WITH ("qSpeedTest:")) return eServerPacketType_qSpeedTest;
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
if (PACKET_MATCHES ("qShlibInfoAddr")) return eServerPacketType_qShlibInfoAddr;
if (PACKET_MATCHES ("qStepPacketSupported")) return eServerPacketType_qStepPacketSupported;
Add lldb-gdbserver support for Linux x86_64. This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64. (More architectures coming soon). Not every debugserver option is covered yet. Currently the lldb-gdbserver command line can start unattached, start attached to a pid (process-name attach not supported yet), or accept lldb attaching and launching a process or connecting by process id. The history of this large change can be found here: https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64 Until mid/late April, I was not sharing the work and continued to rebase it off of head (developed via id tfiala@google.com). I switched over to user todd.fiala@gmail.com in the middle, and once I went to github, I did merges rather than rebasing so I could share with others. llvm-svn: 212069
2014-07-01 05:05:18 +08:00
if (PACKET_STARTS_WITH ("qSupported")) return eServerPacketType_qSupported;
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
if (PACKET_MATCHES ("qSyncThreadStateSupported")) return eServerPacketType_qSyncThreadStateSupported;
break;
case 'T':
if (PACKET_STARTS_WITH ("qThreadExtraInfo,")) return eServerPacketType_qThreadExtraInfo;
if (PACKET_STARTS_WITH ("qThreadStopInfo")) return eServerPacketType_qThreadStopInfo;
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
break;
case 'U':
if (PACKET_STARTS_WITH ("qUserName:")) return eServerPacketType_qUserName;
break;
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
case 'V':
if (PACKET_MATCHES ("qVAttachOrWaitSupported")) return eServerPacketType_qVAttachOrWaitSupported;
break;
case 'W':
if (PACKET_STARTS_WITH ("qWatchpointSupportInfo:")) return eServerPacketType_qWatchpointSupportInfo;
if (PACKET_MATCHES ("qWatchpointSupportInfo")) return eServerPacketType_qWatchpointSupportInfoSupported;
break;
Add lldb-gdbserver support for Linux x86_64. This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64. (More architectures coming soon). Not every debugserver option is covered yet. Currently the lldb-gdbserver command line can start unattached, start attached to a pid (process-name attach not supported yet), or accept lldb attaching and launching a process or connecting by process id. The history of this large change can be found here: https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64 Until mid/late April, I was not sharing the work and continued to rebase it off of head (developed via id tfiala@google.com). I switched over to user todd.fiala@gmail.com in the middle, and once I went to github, I did merges rather than rebasing so I could share with others. llvm-svn: 212069
2014-07-01 05:05:18 +08:00
case 'X':
if (PACKET_STARTS_WITH ("qXfer:auxv:read::")) return eServerPacketType_qXfer_auxv_read;
break;
Moved the execution context that was in the Debugger into 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
2011-04-12 13:54:46 +08:00
}
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
break;
Refactor Unix signals. Summary: - Consolidate Unix signals selection in UnixSignals. - Make Unix signals available from platform. - Add jSignalsInfo packet to retrieve Unix signals from remote platform. - Get a copy of the platform signal for each remote process. - Update SB API for signals. - Update signal utility in test suite. Reviewers: ovyalov, clayborg Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11094 llvm-svn: 242101
2015-07-14 09:09:28 +08:00
case 'j':
Fix jSignalsInfo packet handling. llvm-svn: 243257
2015-07-27 09:32:58 +08:00
if (PACKET_MATCHES("jSignalsInfo")) return eServerPacketType_jSignalsInfo;
Add jThreadsInfo support to lldb-server Summary: This commit adds initial support for the jThreadsInfo packet to lldb-server. The current implementation does not expedite inferior memory. I have also added a description of the new packet to our protocol documentation (mostly taken from Greg's earlier commit message). Reviewers: clayborg, ovyalov, tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11187 llvm-svn: 242402
2015-07-16 22:14:35 +08:00
if (PACKET_MATCHES("jThreadsInfo")) return eServerPacketType_jThreadsInfo;
Fix all of the unannotated switch cases to annotate the fall through or do the right thing and break. llvm-svn: 261950
2016-02-26 09:20:20 +08:00
break;
Refactor Unix signals. Summary: - Consolidate Unix signals selection in UnixSignals. - Make Unix signals available from platform. - Add jSignalsInfo packet to retrieve Unix signals from remote platform. - Get a copy of the platform signal for each remote process. - Update SB API for signals. - Update signal utility in test suite. Reviewers: ovyalov, clayborg Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11094 llvm-svn: 242101
2015-07-14 09:09:28 +08:00
merge lldb-platform-work branch (and assorted fixes) into trunk Summary: This merge brings in the improved 'platform' command that knows how to interface with remote machines; that is, query OS/kernel information, push and pull files, run shell commands, etc... and implementation for the new communication packets that back that interface, at least on Darwin based operating systems via the POSIXPlatform class. Linux support is coming soon. Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS X Mountain Lion. Additional improvements (not in the source SVN branch 'lldb-platform-work'): - cmake build scripts for lldb-platform - cleanup test suite - documentation stub for qPlatform_RunCommand - use log class instead of printf() directly - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely. - add new logging category 'platform' Reviewers: Matt Kopec, Greg Clayton Review: http://llvm-reviews.chandlerc.com/D1493 llvm-svn: 189295
2013-08-27 07:57:52 +08:00
case 'v':
if (PACKET_STARTS_WITH("vFile:"))
{
Expose SBPlatform through the public API. Example code: remote_platform = lldb.SBPlatform("remote-macosx"); remote_platform.SetWorkingDirectory("/private/tmp") debugger.SetSelectedPlatform(remote_platform) connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111"); err = remote_platform.ConnectRemote(connect_options) if err.Success(): print >> result, 'Connected to remote platform:' print >> result, 'hostname: %s' % (remote_platform.GetHostname()) src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False) dst = lldb.SBFileSpec() # copy src to platform working directory since "dst" is empty err = remote_platform.Install(src, dst); if err.Success(): print >> result, '%s installed successfully' % (src) else: print >> result, 'error: failed to install "%s": %s' % (src, err) Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories. The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform. The API in SBPlatform is subject to change and will be getting many new functions. llvm-svn: 195273
2013-11-21 05:07:01 +08:00
if (PACKET_STARTS_WITH("vFile:open:")) return eServerPacketType_vFile_open;
else if (PACKET_STARTS_WITH("vFile:close:")) return eServerPacketType_vFile_close;
else if (PACKET_STARTS_WITH("vFile:pread")) return eServerPacketType_vFile_pread;
else if (PACKET_STARTS_WITH("vFile:pwrite")) return eServerPacketType_vFile_pwrite;
else if (PACKET_STARTS_WITH("vFile:size")) return eServerPacketType_vFile_size;
else if (PACKET_STARTS_WITH("vFile:exists")) return eServerPacketType_vFile_exists;
else if (PACKET_STARTS_WITH("vFile:stat")) return eServerPacketType_vFile_stat;
else if (PACKET_STARTS_WITH("vFile:mode")) return eServerPacketType_vFile_mode;
else if (PACKET_STARTS_WITH("vFile:MD5")) return eServerPacketType_vFile_md5;
else if (PACKET_STARTS_WITH("vFile:symlink")) return eServerPacketType_vFile_symlink;
else if (PACKET_STARTS_WITH("vFile:unlink")) return eServerPacketType_vFile_unlink;
merge lldb-platform-work branch (and assorted fixes) into trunk Summary: This merge brings in the improved 'platform' command that knows how to interface with remote machines; that is, query OS/kernel information, push and pull files, run shell commands, etc... and implementation for the new communication packets that back that interface, at least on Darwin based operating systems via the POSIXPlatform class. Linux support is coming soon. Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS X Mountain Lion. Additional improvements (not in the source SVN branch 'lldb-platform-work'): - cmake build scripts for lldb-platform - cleanup test suite - documentation stub for qPlatform_RunCommand - use log class instead of printf() directly - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely. - add new logging category 'platform' Reviewers: Matt Kopec, Greg Clayton Review: http://llvm-reviews.chandlerc.com/D1493 llvm-svn: 189295
2013-08-27 07:57:52 +08:00
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
} else {
if (PACKET_STARTS_WITH ("vAttach;")) return eServerPacketType_vAttach;
if (PACKET_STARTS_WITH ("vAttachWait;")) return eServerPacketType_vAttachWait;
if (PACKET_STARTS_WITH ("vAttachOrWait;")) return eServerPacketType_vAttachOrWait;
if (PACKET_STARTS_WITH ("vAttachName;")) return eServerPacketType_vAttachName;
if (PACKET_STARTS_WITH("vCont;")) return eServerPacketType_vCont;
if (PACKET_MATCHES ("vCont?")) return eServerPacketType_vCont_actions;
merge lldb-platform-work branch (and assorted fixes) into trunk Summary: This merge brings in the improved 'platform' command that knows how to interface with remote machines; that is, query OS/kernel information, push and pull files, run shell commands, etc... and implementation for the new communication packets that back that interface, at least on Darwin based operating systems via the POSIXPlatform class. Linux support is coming soon. Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS X Mountain Lion. Additional improvements (not in the source SVN branch 'lldb-platform-work'): - cmake build scripts for lldb-platform - cleanup test suite - documentation stub for qPlatform_RunCommand - use log class instead of printf() directly - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely. - add new logging category 'platform' Reviewers: Matt Kopec, Greg Clayton Review: http://llvm-reviews.chandlerc.com/D1493 llvm-svn: 189295
2013-08-27 07:57:52 +08:00
}
break;
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
case '_':
switch (packet_cstr[1])
{
case 'M':
return eServerPacketType__M;
case 'm':
return eServerPacketType__m;
}
break;
case '?':
if (packet_size == 1) return eServerPacketType_stop_reason;
break;
case 'c':
return eServerPacketType_c;
case 'C':
return eServerPacketType_C;
case 'D':
if (packet_size == 1) return eServerPacketType_D;
break;
case 'g':
if (packet_size == 1) return eServerPacketType_g;
break;
case 'G':
return eServerPacketType_G;
case 'H':
return eServerPacketType_H;
Add support for SBProcess::PutSTDIN to remote processes Processes running on a remote target can already send $O messages to send stdout but there is no way to send stdin to a remote inferior. This allows processes using the API to pump stdin into a remote inferior process. It fixes a hang in TestProcessIO.py when running against a remote target. llvm-svn: 228419
2015-02-07 02:32:57 +08:00
case 'I':
return eServerPacketType_I;
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
case 'k':
if (packet_size == 1) return eServerPacketType_k;
break;
case 'm':
return eServerPacketType_m;
case 'M':
return eServerPacketType_M;
case 'p':
return eServerPacketType_p;
case 'P':
return eServerPacketType_P;
case 's':
if (packet_size == 1) return eServerPacketType_s;
break;
case 'S':
return eServerPacketType_S;
lldb-server: add support for binary memory reads Summary: This commit adds support for binary memory reads ($x) to lldb-server. It also removes the "0x" prefix from the $x client packet, to make it more compatible with the old $m packet. This allows us to use almost the same code for handling both packet types. I have verified that debugserver correctly handles $x packets even without the leading "0x". I have added a test which verifies that the stub returns the same memory contents for both kinds of memory reads ($x and $m). Reviewers: tberghammer, jasonmolenda Subscribers: iancottrell, lldb-commits Differential Revision: http://reviews.llvm.org/D13695 llvm-svn: 250295
2015-10-14 20:59:37 +08:00
case 'x':
return eServerPacketType_x;
case 'X':
return eServerPacketType_X;
Extends StringExtractorGDBRemote to support debugger packets. CC: lldb-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2337 llvm-svn: 196525
2013-12-06 03:25:45 +08:00
case 'T':
return eServerPacketType_T;
case 'z':
if (packet_cstr[1] >= '0' && packet_cstr[1] <= '4')
return eServerPacketType_z;
break;
case 'Z':
if (packet_cstr[1] >= '0' && packet_cstr[1] <= '4')
return eServerPacketType_Z;
break;
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
}
return eServerPacketType_unimplemented;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
StringExtractorGDBRemote::IsOKResponse() const
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
return GetResponseType () == eOK;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
bool
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
StringExtractorGDBRemote::IsUnsupportedResponse() const
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
return GetResponseType () == eUnsupported;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
bool
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
StringExtractorGDBRemote::IsNormalResponse() const
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
return GetResponseType () == eResponse;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
bool
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
StringExtractorGDBRemote::IsErrorResponse() const
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
return GetResponseType () == eError &&
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_packet.size() == 3 &&
isxdigit(m_packet[1]) &&
isxdigit(m_packet[2]);
}
uint8_t
StringExtractorGDBRemote::GetError ()
{
Split the GDBRemoteCommunication class into three classes: 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
2011-03-22 12:00:09 +08:00
if (GetResponseType() == eError)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
SetFilePos(1);
return GetHexU8(255);
}
return 0;
}
merge lldb-platform-work branch (and assorted fixes) into trunk Summary: This merge brings in the improved 'platform' command that knows how to interface with remote machines; that is, query OS/kernel information, push and pull files, run shell commands, etc... and implementation for the new communication packets that back that interface, at least on Darwin based operating systems via the POSIXPlatform class. Linux support is coming soon. Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS X Mountain Lion. Additional improvements (not in the source SVN branch 'lldb-platform-work'): - cmake build scripts for lldb-platform - cleanup test suite - documentation stub for qPlatform_RunCommand - use log class instead of printf() directly - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely. - add new logging category 'platform' Reviewers: Matt Kopec, Greg Clayton Review: http://llvm-reviews.chandlerc.com/D1493 llvm-svn: 189295
2013-08-27 07:57:52 +08:00
size_t
StringExtractorGDBRemote::GetEscapedBinaryData (std::string &str)
{
Fix the ability of "lldb-platform" to upload files. The issue was GDBRemoteCommunication::CheckForPacket() already fixes up any prefixed bytes (0x7d followed by value that is XOR'ed with 0x20). If we do this again, we cause binary packets to lose bytes. This allows lldb-platform to be able to upload binaries and debug them remotely. llvm-svn: 218002
2014-09-18 08:20:51 +08:00
// Just get the data bytes in the string as GDBRemoteCommunication::CheckForPacket()
// already removes any 0x7d escaped characters. If any 0x7d characters are left in
// the packet, then they are supposed to be there...
merge lldb-platform-work branch (and assorted fixes) into trunk Summary: This merge brings in the improved 'platform' command that knows how to interface with remote machines; that is, query OS/kernel information, push and pull files, run shell commands, etc... and implementation for the new communication packets that back that interface, at least on Darwin based operating systems via the POSIXPlatform class. Linux support is coming soon. Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS X Mountain Lion. Additional improvements (not in the source SVN branch 'lldb-platform-work'): - cmake build scripts for lldb-platform - cleanup test suite - documentation stub for qPlatform_RunCommand - use log class instead of printf() directly - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely. - add new logging category 'platform' Reviewers: Matt Kopec, Greg Clayton Review: http://llvm-reviews.chandlerc.com/D1493 llvm-svn: 189295
2013-08-27 07:57:52 +08:00
str.clear();
Fix the ability of "lldb-platform" to upload files. The issue was GDBRemoteCommunication::CheckForPacket() already fixes up any prefixed bytes (0x7d followed by value that is XOR'ed with 0x20). If we do this again, we cause binary packets to lose bytes. This allows lldb-platform to be able to upload binaries and debug them remotely. llvm-svn: 218002
2014-09-18 08:20:51 +08:00
const size_t bytes_left = GetBytesLeft();
if (bytes_left > 0)
merge lldb-platform-work branch (and assorted fixes) into trunk Summary: This merge brings in the improved 'platform' command that knows how to interface with remote machines; that is, query OS/kernel information, push and pull files, run shell commands, etc... and implementation for the new communication packets that back that interface, at least on Darwin based operating systems via the POSIXPlatform class. Linux support is coming soon. Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS X Mountain Lion. Additional improvements (not in the source SVN branch 'lldb-platform-work'): - cmake build scripts for lldb-platform - cleanup test suite - documentation stub for qPlatform_RunCommand - use log class instead of printf() directly - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely. - add new logging category 'platform' Reviewers: Matt Kopec, Greg Clayton Review: http://llvm-reviews.chandlerc.com/D1493 llvm-svn: 189295
2013-08-27 07:57:52 +08:00
{
Fix the ability of "lldb-platform" to upload files. The issue was GDBRemoteCommunication::CheckForPacket() already fixes up any prefixed bytes (0x7d followed by value that is XOR'ed with 0x20). If we do this again, we cause binary packets to lose bytes. This allows lldb-platform to be able to upload binaries and debug them remotely. llvm-svn: 218002
2014-09-18 08:20:51 +08:00
str.assign(m_packet, m_index, bytes_left);
m_index += bytes_left;
merge lldb-platform-work branch (and assorted fixes) into trunk Summary: This merge brings in the improved 'platform' command that knows how to interface with remote machines; that is, query OS/kernel information, push and pull files, run shell commands, etc... and implementation for the new communication packets that back that interface, at least on Darwin based operating systems via the POSIXPlatform class. Linux support is coming soon. Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS X Mountain Lion. Additional improvements (not in the source SVN branch 'lldb-platform-work'): - cmake build scripts for lldb-platform - cleanup test suite - documentation stub for qPlatform_RunCommand - use log class instead of printf() directly - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely. - add new logging category 'platform' Reviewers: Matt Kopec, Greg Clayton Review: http://llvm-reviews.chandlerc.com/D1493 llvm-svn: 189295
2013-08-27 07:57:52 +08:00
}
return str.size();
}