maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/Plugins/ABI/SysV-x86_64/ABISysV_x86_64.h

132 lines
3.7 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
//===-- ABISysV_x86_64.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_ABISysV_x86_64_h_
#define liblldb_ABISysV_x86_64_h_
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
#include "lldb/lldb-private.h"
#include "lldb/Target/ABI.h"
class ABISysV_x86_64 :
public lldb_private::ABI
{
public:
Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their respective ABI plugins as they were plug-ins that supplied ABI specfic info. Also hookep up the UnwindAssemblyInstEmulation so that it can generate the unwind plans for ARM. Changed the way ABI plug-ins are handed out when you get an instance from the plug-in manager. They used to return pointers that would be mananged individually by each client that requested them, but now they are handed out as shared pointers since there is no state in the ABI objects, they can be shared. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
2011-08-22 10:49:39 +08:00
~ABISysV_x86_64()
Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their respective ABI plugins as they were plug-ins that supplied ABI specfic info. Also hookep up the UnwindAssemblyInstEmulation so that it can generate the unwind plans for ARM. Changed the way ABI plug-ins are handed out when you get an instance from the plug-in manager. They used to return pointers that would be mananged individually by each client that requested them, but now they are handed out as shared pointers since there is no state in the ABI objects, they can be shared. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
{
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
virtual size_t
GetRedZoneSize () const;
virtual bool
Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their respective ABI plugins as they were plug-ins that supplied ABI specfic info. Also hookep up the UnwindAssemblyInstEmulation so that it can generate the unwind plans for ARM. Changed the way ABI plug-ins are handed out when you get an instance from the plug-in manager. They used to return pointers that would be mananged individually by each client that requested them, but now they are handed out as shared pointers since there is no state in the ABI objects, they can be shared. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
PrepareTrivialCall (lldb_private::Thread &thread,
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
lldb::addr_t sp,
lldb::addr_t functionAddress,
lldb::addr_t returnAddress,
Expand the ABI prepare trivial function call to allow 6 simple args. llvm-svn: 131334
2011-05-14 09:50:35 +08:00
lldb::addr_t *arg1_ptr = NULL,
lldb::addr_t *arg2_ptr = NULL,
lldb::addr_t *arg3_ptr = NULL,
lldb::addr_t *arg4_ptr = NULL,
lldb::addr_t *arg5_ptr = NULL,
lldb::addr_t *arg6_ptr = NULL) const;
Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their respective ABI plugins as they were plug-ins that supplied ABI specfic info. Also hookep up the UnwindAssemblyInstEmulation so that it can generate the unwind plans for ARM. Changed the way ABI plug-ins are handed out when you get an instance from the plug-in manager. They used to return pointers that would be mananged individually by each client that requested them, but now they are handed out as shared pointers since there is no state in the ABI objects, they can be shared. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
virtual bool
GetArgumentValues (lldb_private::Thread &thread,
lldb_private::ValueList &values) const;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Start at getting "thread return" working. Doesn't work yet. llvm-svn: 163670
2012-09-12 08:40:39 +08:00
virtual lldb_private::Error
SetReturnValueObject(lldb::StackFrameSP &frame_sp, lldb::ValueObjectSP &new_value);
Improve the x86_64 return value decoder to handle most structure returns. Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject which is much more convenient. Return the "return value object" as a persistent variable if requested. llvm-svn: 147157
2011-12-23 03:12:40 +08:00
protected:
lldb::ValueObjectSP
GetReturnValueObjectSimple (lldb_private::Thread &thread,
lldb_private::ClangASTType &ast_type) const;
public:
virtual lldb::ValueObjectSP
GetReturnValueObjectImpl (lldb_private::Thread &thread,
lldb_private::ClangASTType &type) const;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
virtual bool
Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their respective ABI plugins as they were plug-ins that supplied ABI specfic info. Also hookep up the UnwindAssemblyInstEmulation so that it can generate the unwind plans for ARM. Changed the way ABI plug-ins are handed out when you get an instance from the plug-in manager. They used to return pointers that would be mananged individually by each client that requested them, but now they are handed out as shared pointers since there is no state in the ABI objects, they can be shared. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
CreateFunctionEntryUnwindPlan (lldb_private::UnwindPlan &unwind_plan);
virtual bool
CreateDefaultUnwindPlan (lldb_private::UnwindPlan &unwind_plan);
virtual bool
RegisterIsVolatile (const lldb_private::RegisterInfo *reg_info);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
ABI plug-ins must implement the following pure virtual functions: virtual bool ABI::StackUsesFrames () = 0; Should return true if your ABI uses frames when doing stack backtraces. This means a frame pointer is used that points to the previous stack frame in some way or another. virtual bool ABI::CallFrameAddressIsValid (lldb::addr_t cfa) = 0; Should take a look at a call frame address (CFA) which is just the stack pointer value upon entry to a function. ABIs usually impose alignment restrictions (4, 8 or 16 byte aligned), and zero is usually not allowed. This function should return true if "cfa" is valid call frame address for the ABI, and false otherwise. This is used by the generic stack frame unwinding code to help determine when a stack ends. virtual bool ABI::CodeAddressIsValid (lldb::addr_t pc) = 0; Validates a possible PC value and returns true if an opcode can be at "pc". Some ABIs or architectures have fixed width instructions and must be aligned to a 2 or 4 byte boundary. "pc" can be an opcode or a callable address which means the load address might be decorated with extra bits (such as bit zero to indicate a thumb function call for ARM targets), so take this into account when returning true or false. The address should also be validated to ensure it is a valid address for the address size of the inferior process. 32 bit targets should make sure the address is less than UINT32_MAX. Modified UnwindLLDB to use the new ABI functions to help it properly terminate stacks. Modified the mach-o function that extracts dependent files to not resolve the path as the paths inside a binary might not match those on the current host system. llvm-svn: 132021
2011-05-25 07:06:02 +08:00
virtual bool
StackUsesFrames ()
{
return true;
}
virtual bool
CallFrameAddressIsValid (lldb::addr_t cfa)
{
// Make sure the stack call frame addresses are are 8 byte aligned
if (cfa & (8ull - 1ull))
return false; // Not 8 byte aligned
if (cfa == 0)
return false; // Zero is not a valid stack address
return true;
}
virtual bool
CodeAddressIsValid (lldb::addr_t pc)
{
// We have a 64 bit address space, so anything is valid as opcodes
// aren't fixed width...
return true;
}
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
2011-08-22 10:49:39 +08:00
virtual const lldb_private::RegisterInfo *
GetRegisterInfoArray (uint32_t &count);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//------------------------------------------------------------------
// Static Functions
//------------------------------------------------------------------
static void
Initialize();
static void
Terminate();
Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their respective ABI plugins as they were plug-ins that supplied ABI specfic info. Also hookep up the UnwindAssemblyInstEmulation so that it can generate the unwind plans for ARM. Changed the way ABI plug-ins are handed out when you get an instance from the plug-in manager. They used to return pointers that would be mananged individually by each client that requested them, but now they are handed out as shared pointers since there is no state in the ABI objects, they can be shared. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
static lldb::ABISP
CreateInstance (const lldb_private::ArchSpec &arch);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//------------------------------------------------------------------
// PluginInterface protocol
//------------------------------------------------------------------
virtual const char *
GetPluginName();
virtual const char *
GetShortPluginName();
virtual uint32_t
GetPluginVersion();
protected:
Added a new plug-in type: lldb_private::OperatingSystem. The operating system plug-ins are add on plug-ins for the lldb_private::Process class that can add thread contexts that are read from memory. It is common in kernels to have a lot of threads that are not currently executing on any cores (JTAG debugging also follows this sort of thing) and are context switched out whose state is stored in memory data structures. Clients can now subclass the OperatingSystem plug-ins and then make sure their Create functions correcltly only enable themselves when the right binary/target triple are being debugged. The operating system plug-ins get a chance to attach themselves to processes just after launching or attaching and are given a lldb_private::Process object pointer which can be inspected to see if the main executable, target triple, or any shared libraries match a case where the OS plug-in should be used. Currently the OS plug-ins can create new threads, define the register contexts for these threads (which can all be different if desired), and populate and manage the thread info (stop reason, registers in the register context) as the debug session goes on. llvm-svn: 138228
2011-08-22 10:49:39 +08:00
void
CreateRegisterMapIfNeeded ();
Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their respective ABI plugins as they were plug-ins that supplied ABI specfic info. Also hookep up the UnwindAssemblyInstEmulation so that it can generate the unwind plans for ARM. Changed the way ABI plug-ins are handed out when you get an instance from the plug-in manager. They used to return pointers that would be mananged individually by each client that requested them, but now they are handed out as shared pointers since there is no state in the ABI objects, they can be shared. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
bool
RegisterIsCalleeSaved (const lldb_private::RegisterInfo *reg_info);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
private:
ABISysV_x86_64() : lldb_private::ABI() { } // Call CreateInstance instead.
};
#endif // liblldb_ABI_h_