llvm-project/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h

398 lines
12 KiB
C
Raw Normal View History

//===-- ProcessGDBRemote.h --------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#ifndef liblldb_ProcessGDBRemote_h_
#define liblldb_ProcessGDBRemote_h_
// C Includes
// C++ Includes
#include <list>
#include <vector>
// Other libraries and framework includes
#include "lldb/Core/ArchSpec.h"
#include "lldb/Core/Broadcaster.h"
#include "lldb/Core/ConstString.h"
#include "lldb/Core/Error.h"
#include "lldb/Core/StreamString.h"
#include "lldb/Core/StringList.h"
#include "lldb/Core/ThreadSafeValue.h"
#include "lldb/Target/Process.h"
#include "lldb/Target/Thread.h"
#include "GDBRemoteCommunicationClient.h"
#include "Utility/StringExtractor.h"
#include "GDBRemoteRegisterContext.h"
class ThreadGDBRemote;
class ProcessGDBRemote : public lldb_private::Process
{
public:
//------------------------------------------------------------------
// Constructors and Destructors
//------------------------------------------------------------------
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
2012-02-09 14:16:32 +08:00
static lldb::ProcessSP
CreateInstance (lldb_private::Target& target,
lldb_private::Listener &listener,
const lldb_private::FileSpec *crash_file_path);
static void
Initialize();
static void
DebuggerInitialize (lldb_private::Debugger &debugger);
static void
Terminate();
static lldb_private::ConstString
GetPluginNameStatic();
static const char *
GetPluginDescriptionStatic();
//------------------------------------------------------------------
// Constructors and Destructors
//------------------------------------------------------------------
ProcessGDBRemote(lldb_private::Target& target, lldb_private::Listener &listener);
virtual
~ProcessGDBRemote();
//------------------------------------------------------------------
// Check if a given Process
//------------------------------------------------------------------
virtual bool
CanDebug (lldb_private::Target &target,
bool plugin_specified_by_name);
virtual lldb_private::CommandObject *
GetPluginCommandObject();
//------------------------------------------------------------------
// Creating a new process, or attaching to an existing one
//------------------------------------------------------------------
virtual lldb_private::Error
WillLaunch (lldb_private::Module* module);
virtual lldb_private::Error
DoLaunch (lldb_private::Module *exe_module,
lldb_private::ProcessLaunchInfo &launch_info);
virtual void
DidLaunch ();
virtual lldb_private::Error
2010-11-18 13:57:03 +08:00
WillAttachToProcessWithID (lldb::pid_t pid);
virtual lldb_private::Error
2010-11-18 13:57:03 +08:00
WillAttachToProcessWithName (const char *process_name, bool wait_for_launch);
Added support for attaching to a remote debug server with the new command: (lldb) process connect <remote-url> Currently when you specify a file with the file command it helps us to find a process plug-in that is suitable for debugging. If you specify a file you can rely upon this to find the correct debugger plug-in: % lldb a.out Current executable set to 'a.out' (x86_64). (lldb) process connect connect://localhost:2345 ... If you don't specify a file, you will need to specify the plug-in name that you wish to use: % lldb (lldb) process connect --plugin process.gdb-remote connect://localhost:2345 Other connection URL examples: (lldb) process connect connect://localhost:2345 (lldb) process connect tcp://127.0.0.1 (lldb) process connect file:///dev/ttyS1 We are currently treating the "connect://host:port" as a way to do raw socket connections. If there is a URL for this already, please let me know and we will adopt it. So now you can connect to a remote debug server with the ProcessGDBRemote plug-in. After connection, it will ask for the pid info using the "qC" packet and if it responds with a valid process ID, it will be equivalent to attaching. If it response with an error or invalid process ID, the LLDB process will be in a new state: eStateConnected. This allows us to then download a program or specify the program to run (using the 'A' packet), or specify a process to attach to (using the "vAttach" packets), or query info about the processes that might be available. llvm-svn: 124846
2011-02-04 09:58:07 +08:00
virtual lldb_private::Error
DoConnectRemote (lldb_private::Stream *strm, const char *remote_url);
Added support for attaching to a remote debug server with the new command: (lldb) process connect <remote-url> Currently when you specify a file with the file command it helps us to find a process plug-in that is suitable for debugging. If you specify a file you can rely upon this to find the correct debugger plug-in: % lldb a.out Current executable set to 'a.out' (x86_64). (lldb) process connect connect://localhost:2345 ... If you don't specify a file, you will need to specify the plug-in name that you wish to use: % lldb (lldb) process connect --plugin process.gdb-remote connect://localhost:2345 Other connection URL examples: (lldb) process connect connect://localhost:2345 (lldb) process connect tcp://127.0.0.1 (lldb) process connect file:///dev/ttyS1 We are currently treating the "connect://host:port" as a way to do raw socket connections. If there is a URL for this already, please let me know and we will adopt it. So now you can connect to a remote debug server with the ProcessGDBRemote plug-in. After connection, it will ask for the pid info using the "qC" packet and if it responds with a valid process ID, it will be equivalent to attaching. If it response with an error or invalid process ID, the LLDB process will be in a new state: eStateConnected. This allows us to then download a program or specify the program to run (using the 'A' packet), or specify a process to attach to (using the "vAttach" packets), or query info about the processes that might be available. llvm-svn: 124846
2011-02-04 09:58:07 +08:00
lldb_private::Error
WillLaunchOrAttach ();
virtual lldb_private::Error
DoAttachToProcessWithID (lldb::pid_t pid);
virtual lldb_private::Error
DoAttachToProcessWithID (lldb::pid_t pid, const lldb_private::ProcessAttachInfo &attach_info);
virtual lldb_private::Error
DoAttachToProcessWithName (const char *process_name,
const lldb_private::ProcessAttachInfo &attach_info);
virtual void
DidAttach ();
//------------------------------------------------------------------
// PluginInterface protocol
//------------------------------------------------------------------
virtual lldb_private::ConstString
GetPluginName();
virtual uint32_t
GetPluginVersion();
//------------------------------------------------------------------
// Process Control
//------------------------------------------------------------------
virtual lldb_private::Error
WillResume ();
virtual lldb_private::Error
DoResume ();
virtual lldb_private::Error
DoHalt (bool &caused_stop);
virtual lldb_private::Error
DoDetach (bool keep_stopped);
virtual bool
DetachRequiresHalt() { return true; }
virtual lldb_private::Error
DoSignal (int signal);
virtual lldb_private::Error
DoDestroy ();
virtual void
RefreshStateAfterStop();
//------------------------------------------------------------------
// Process Queries
//------------------------------------------------------------------
virtual bool
IsAlive ();
virtual lldb::addr_t
GetImageInfoAddress();
//------------------------------------------------------------------
// Process Memory
//------------------------------------------------------------------
virtual size_t
DoReadMemory (lldb::addr_t addr, void *buf, size_t size, lldb_private::Error &error);
virtual size_t
DoWriteMemory (lldb::addr_t addr, const void *buf, size_t size, lldb_private::Error &error);
virtual lldb::addr_t
DoAllocateMemory (size_t size, uint32_t permissions, lldb_private::Error &error);
virtual lldb_private::Error
GetMemoryRegionInfo (lldb::addr_t load_addr,
lldb_private::MemoryRegionInfo &region_info);
virtual lldb_private::Error
DoDeallocateMemory (lldb::addr_t ptr);
//------------------------------------------------------------------
// Process STDIO
//------------------------------------------------------------------
virtual size_t
PutSTDIN (const char *buf, size_t buf_size, lldb_private::Error &error);
//----------------------------------------------------------------------
// Process Breakpoints
//----------------------------------------------------------------------
virtual lldb_private::Error
EnableBreakpointSite (lldb_private::BreakpointSite *bp_site);
virtual lldb_private::Error
DisableBreakpointSite (lldb_private::BreakpointSite *bp_site);
//----------------------------------------------------------------------
// Process Watchpoints
//----------------------------------------------------------------------
virtual lldb_private::Error
EnableWatchpoint (lldb_private::Watchpoint *wp, bool notify = true);
virtual lldb_private::Error
DisableWatchpoint (lldb_private::Watchpoint *wp, bool notify = true);
virtual lldb_private::Error
GetWatchpointSupportInfo (uint32_t &num);
virtual lldb_private::Error
GetWatchpointSupportInfo (uint32_t &num, bool& after);
virtual bool
StartNoticingNewThreads();
virtual bool
StopNoticingNewThreads();
GDBRemoteCommunicationClient &
GetGDBRemote()
{
return m_gdb_comm;
}
//----------------------------------------------------------------------
// Override SetExitStatus so we can disconnect from the remote GDB server
//----------------------------------------------------------------------
virtual bool
SetExitStatus (int exit_status, const char *cstr);
protected:
friend class ThreadGDBRemote;
friend class GDBRemoteCommunicationClient;
friend class GDBRemoteRegisterContext;
//----------------------------------------------------------------------
// Accessors
//----------------------------------------------------------------------
bool
IsRunning ( lldb::StateType state )
{
return state == lldb::eStateRunning || IsStepping(state);
}
bool
IsStepping ( lldb::StateType state)
{
return state == lldb::eStateStepping;
}
bool
CanResume ( lldb::StateType state)
{
return state == lldb::eStateStopped;
}
bool
HasExited (lldb::StateType state)
{
return state == lldb::eStateExited;
}
bool
ProcessIDIsValid ( ) const;
void
Clear ( );
lldb_private::Flags &
GetFlags ()
{
return m_flags;
}
const lldb_private::Flags &
GetFlags () const
{
return m_flags;
}
virtual bool
UpdateThreadList (lldb_private::ThreadList &old_thread_list,
lldb_private::ThreadList &new_thread_list);
lldb_private::Error
LaunchAndConnectToDebugserver (const lldb_private::ProcessInfo &process_info);
void
KillDebugserverProcess ();
void
BuildDynamicRegisterInfo (bool force);
void
SetLastStopPacket (const StringExtractorGDBRemote &response);
<rdar://problem/14972424> When debugging with the GDB remote in LLDB, LLDB uses special packets to discover the registers on the remote server. When those packets aren't supported, LLDB doesn't know what the registers look like. This checkin implements a setting that can be used to specify a python file that contains the registers definitions. The setting is: (lldb) settings set plugin.process.gdb-remote.target-definition-file /path/to/module.py Inside module there should be a function: def get_dynamic_setting(target, setting_name): This dynamic setting function is handed the "target" which is a SBTarget, and the "setting_name", which is the name of the dynamic setting to retrieve. For the GDB remote target definition the setting name is 'gdb-server-target-definition'. The return value is a dictionary that follows the same format as the OperatingSystem plugins follow. I have checked in an example file that implements the x86_64 GDB register set for people to see: examples/python/x86_64_target_definition.py This allows LLDB to debug to any archticture that is support and allows users to define the registers contexts when the discovery packets (qRegisterInfo, qHostInfo) are not supported by the remote GDB server. A few benefits of doing this in Python: 1 - The dynamic register context was already supported in the OperatingSystem plug-in 2 - Register contexts can use all of the LLDB enumerations and definitions for things like lldb::Format, lldb::Encoding, generic register numbers, invalid registers numbers, etc. 3 - The code that generates the register context can use the program to calculate the register context contents (like offsets, register numbers, and more) 4 - True dynamic detection could be used where variables and types could be read from the target program itself in order to determine which registers are available since the target is passed into the python function. This is designed to be used instead of XML since it is more dynamic and code flow and functions can be used to make the dictionary. llvm-svn: 192646
2013-10-15 08:14:28 +08:00
bool
ParsePythonTargetDefinition(const lldb_private::FileSpec &target_definition_fspec);
bool
ParseRegisters(lldb_private::ScriptInterpreterObject *registers_array);
//------------------------------------------------------------------
/// Broadcaster event bits definitions.
//------------------------------------------------------------------
enum
{
eBroadcastBitAsyncContinue = (1 << 0),
eBroadcastBitAsyncThreadShouldExit = (1 << 1),
eBroadcastBitAsyncThreadDidExit = (1 << 2)
};
typedef enum AsyncThreadState
{
eAsyncThreadNotStarted,
eAsyncThreadRunning,
eAsyncThreadDone
} AsyncThreadState;
lldb_private::Flags m_flags; // Process specific flags (see eFlags enums)
GDBRemoteCommunicationClient m_gdb_comm;
lldb::pid_t m_debugserver_pid;
StringExtractorGDBRemote m_last_stop_packet;
lldb_private::Mutex m_last_stop_packet_mutex;
GDBRemoteDynamicRegisterInfo m_register_info;
lldb_private::Broadcaster m_async_broadcaster;
lldb::thread_t m_async_thread;
AsyncThreadState m_async_thread_state;
lldb_private::Mutex m_async_thread_state_mutex;
typedef std::vector<lldb::tid_t> tid_collection;
typedef std::vector< std::pair<lldb::tid_t,int> > tid_sig_collection;
Added the ability to get the return value from a ThreadPlanCallFunction thread plan. In order to get the return value, you can call: void ThreadPlanCallFunction::RequestReturnValue (lldb::ValueSP &return_value_sp); This registers a shared pointer to a return value that will get filled in if everything goes well. After the thread plan is run the return value will be extracted for you. Added an ifdef to be able to switch between the LLVM MCJIT and the standand JIT. We currently have the standard JIT selected because we have some work to do to get the MCJIT fuctioning properly. Added the ability to call functions with 6 argument in the x86_64 ABI. Added the ability for GDBRemoteCommunicationClient to detect if the allocate and deallocate memory packets are supported and to not call allocate memory ("_M") or deallocate ("_m") if we find they aren't supported. Modified the ProcessGDBRemote::DoAllocateMemory(...) and ProcessGDBRemote::DoDeallocateMemory(...) to be able to deal with the allocate and deallocate memory packets not being supported. If they are not supported, ProcessGDBRemote will switch to calling "mmap" and "munmap" to allocate and deallocate memory instead using our trivial function call support. Modified the "void ProcessGDBRemote::DidLaunchOrAttach()" to correctly ignore the qHostInfo triple information if any was specified in the target. Currently if the target only specifies an architecture when creating the target: (lldb) target create --arch i386 a.out Then the vendor, os and environemnt will be adopted by the target. If the target was created with any triple that specifies more than the arch: (lldb) target create --arch i386-unknown-unknown a.out Then the target will maintain its triple and not adopt any new values. This can be used to help force bare board debugging where the dynamic loader for static files will get used and users can then use "target modules load ..." to set addressses for any files that are desired. Added back some convenience functions to the lldb_private::RegisterContext class for writing registers with unsigned values. Also made all RegisterContext constructors explicit to make sure we know when an integer is being converted to a RegisterValue. llvm-svn: 131370
2011-05-15 09:25:55 +08:00
typedef std::map<lldb::addr_t, lldb::addr_t> MMapMap;
tid_collection m_thread_ids; // Thread IDs for all threads. This list gets updated after stopping
tid_collection m_continue_c_tids; // 'c' for continue
tid_sig_collection m_continue_C_tids; // 'C' for continue with signal
tid_collection m_continue_s_tids; // 's' for step
tid_sig_collection m_continue_S_tids; // 'S' for step with signal
size_t m_max_memory_size; // The maximum number of bytes to read/write when reading and writing memory
Added the ability to get the return value from a ThreadPlanCallFunction thread plan. In order to get the return value, you can call: void ThreadPlanCallFunction::RequestReturnValue (lldb::ValueSP &return_value_sp); This registers a shared pointer to a return value that will get filled in if everything goes well. After the thread plan is run the return value will be extracted for you. Added an ifdef to be able to switch between the LLVM MCJIT and the standand JIT. We currently have the standard JIT selected because we have some work to do to get the MCJIT fuctioning properly. Added the ability to call functions with 6 argument in the x86_64 ABI. Added the ability for GDBRemoteCommunicationClient to detect if the allocate and deallocate memory packets are supported and to not call allocate memory ("_M") or deallocate ("_m") if we find they aren't supported. Modified the ProcessGDBRemote::DoAllocateMemory(...) and ProcessGDBRemote::DoDeallocateMemory(...) to be able to deal with the allocate and deallocate memory packets not being supported. If they are not supported, ProcessGDBRemote will switch to calling "mmap" and "munmap" to allocate and deallocate memory instead using our trivial function call support. Modified the "void ProcessGDBRemote::DidLaunchOrAttach()" to correctly ignore the qHostInfo triple information if any was specified in the target. Currently if the target only specifies an architecture when creating the target: (lldb) target create --arch i386 a.out Then the vendor, os and environemnt will be adopted by the target. If the target was created with any triple that specifies more than the arch: (lldb) target create --arch i386-unknown-unknown a.out Then the target will maintain its triple and not adopt any new values. This can be used to help force bare board debugging where the dynamic loader for static files will get used and users can then use "target modules load ..." to set addressses for any files that are desired. Added back some convenience functions to the lldb_private::RegisterContext class for writing registers with unsigned values. Also made all RegisterContext constructors explicit to make sure we know when an integer is being converted to a RegisterValue. llvm-svn: 131370
2011-05-15 09:25:55 +08:00
MMapMap m_addr_to_mmap_size;
lldb::BreakpointSP m_thread_create_bp_sp;
bool m_waiting_for_attach;
bool m_destroy_tried_resuming;
lldb::CommandObjectSP m_command_sp;
int64_t m_breakpoint_pc_offset;
bool
StartAsyncThread ();
void
StopAsyncThread ();
static lldb::thread_result_t
AsyncThread (void *arg);
static bool
MonitorDebugserverProcess (void *callback_baton,
lldb::pid_t pid,
bool exited,
int signo,
int exit_status);
lldb::StateType
SetThreadStopInfo (StringExtractor& stop_packet);
void
ClearThreadIDList ();
bool
UpdateThreadIDList ();
void
DidLaunchOrAttach ();
lldb_private::Error
ConnectToDebugserver (const char *host_port);
const char *
GetDispatchQueueNameForThread (lldb::addr_t thread_dispatch_qaddr,
std::string &dispatch_queue_name);
lldb_private::DynamicLoader *
GetDynamicLoader ();
private:
//------------------------------------------------------------------
// For ProcessGDBRemote only
//------------------------------------------------------------------
static bool
NewThreadNotifyBreakpointHit (void *baton,
lldb_private::StoppointCallbackContext *context,
lldb::user_id_t break_id,
lldb::user_id_t break_loc_id);
DISALLOW_COPY_AND_ASSIGN (ProcessGDBRemote);
};
#endif // liblldb_ProcessGDBRemote_h_