Description
Information about calling conventions.
A definition typically comes from external documentation rather than direct analysis.
Definition at line 30 of file Definition.h.
#include <Rose/BinaryAnalysis/CallingConvention/Definition.h>
Public Types | |
| using | Ptr = DefinitionPtr |
| Reference counting pointer to calling convention definition. | |
Public Member Functions | |
| void | clearParameters () |
| Erase all parameters. | |
| const std::vector< ConcreteLocation > & | inputParameters () const |
| Property: Enumerated input parameters. | |
| RegisterParts | inputRegisterParts () const |
| Compute the set of input registers. | |
| void | clearInputParameters () |
| Erase enumerated input parameters. | |
| const std::vector< ConcreteLocation > & | outputParameters () const |
| Property: List of output parameters. | |
| RegisterParts | outputRegisterParts () const |
| Computes the set of output registers. | |
| void | clearOutputParameters () |
| Erase output parameters. | |
| ByteOrder::Endianness | byteOrder () const |
| Property: Order of bytes for multi-byte values in memory. | |
| RegisterParts | calleeSavedRegisterParts () const |
| Compute the set of callee-saved registers. | |
| RegisterParts | scratchRegisterParts () const |
| Computes the set of scratch registers. | |
| RegisterParts | getUsedRegisterParts () const |
| Returns all registers mentioned in this definition. | |
| const std::string & | comment () const |
| Property: Full name of calling convention. | |
| void | comment (const std::string &s) |
| Property: Full name of calling convention. | |
| size_t | bitsPerWord () const |
| Property: Word size in bits. | |
| void | bitsPerWord (const Sawyer::Optional< size_t > &) |
| Property: Word size in bits. | |
| const std::vector< ConcreteLocation > & | nonParameterInputs () const |
| Non-parameter inputs. | |
| std::vector< ConcreteLocation > & | nonParameterInputs () |
| Non-parameter inputs. | |
| void | appendInputParameter (const ConcreteLocation &) |
| Append input parameter. | |
| void | appendInputParameter (RegisterDescriptor reg) |
| Append input parameter. | |
| void | appendInputParameter (RegisterDescriptor reg, int64_t offset) |
| Append input parameter. | |
| void | appendInputParameter (rose_addr_t va) |
| Append input parameter. | |
| void | appendOutputParameter (const ConcreteLocation &) |
| Append output parameter. | |
| void | appendOutputParameter (RegisterDescriptor reg) |
| Append output parameter. | |
| void | appendOutputParameter (RegisterDescriptor reg, int64_t offset) |
| Append output parameter. | |
| void | appendOutputParameter (rose_addr_t va) |
| Append output parameter. | |
| StackParameterOrder | stackParameterOrder () const |
| Property: Stack parameter order. | |
| void | stackParameterOrder (StackParameterOrder x) |
| Property: Stack parameter order. | |
| RegisterDescriptor | stackPointerRegister () const |
| Property: Register for implied stack parameters. | |
| void | stackPointerRegister (RegisterDescriptor) |
| Property: Register for implied stack parameters. | |
| size_t | nonParameterStackSize () const |
| Property: Size of non-parameter stack area. | |
| void | nonParameterStackSize (size_t nBytes) |
| Property: Size of non-parameter stack area. | |
| StackDirection | stackDirection () const |
| Property: Direction that stack grows for a push operation. | |
| void | stackDirection (StackDirection x) |
| Property: Direction that stack grows for a push operation. | |
| StackCleanup | stackCleanup () const |
| Property: Who pops stack parameters. | |
| void | stackCleanup (StackCleanup x) |
| Property: Who pops stack parameters. | |
| const Alignment & | stackAlignment () const |
| Property: Stack alignment. | |
| void | stackAlignment (const Alignment &) |
| Property: Stack alignment. | |
| const ConcreteLocation & | thisParameter () const |
| Property: Object pointer parameter. | |
| void | thisParameter (const ConcreteLocation &x) |
| Property: Object pointer parameter. | |
| void | thisParameter (RegisterDescriptor reg) |
| Property: Object pointer parameter. | |
| void | thisParameter (RegisterDescriptor reg, int64_t offset) |
| Property: Object pointer parameter. | |
| void | thisParameter (rose_addr_t va) |
| Property: Object pointer parameter. | |
| const ConcreteLocation & | returnAddressLocation () const |
| Property: Location of return address. | |
| void | returnAddressLocation (const ConcreteLocation &x) |
| Property: Location of return address. | |
| RegisterDescriptor | instructionPointerRegister () const |
| Property: Register that points to next instruction to execute. | |
| void | instructionPointerRegister (RegisterDescriptor x) |
| Property: Register that points to next instruction to execute. | |
| const std::set< RegisterDescriptor > & | calleeSavedRegisters () const |
| Property: Callee-saved registers. | |
| std::set< RegisterDescriptor > & | calleeSavedRegisters () |
| Property: Callee-saved registers. | |
| const std::set< RegisterDescriptor > & | scratchRegisters () const |
| Property: Scratch registers. | |
| std::set< RegisterDescriptor > & | scratchRegisters () |
| Property: Scratch registers. | |
| AllocatorPtr | returnValueAllocator () const |
| Property: Allocator for return values. | |
| void | returnValueAllocator (const AllocatorPtr &) |
| Property: Allocator for return values. | |
| AllocatorPtr | argumentValueAllocator () const |
| Property: Allocator for argument values. | |
| void | argumentValueAllocator (const AllocatorPtr &) |
| Property: Allocator for argument values. | |
| void | print (std::ostream &) const |
| Print detailed information about this calling convention. | |
| void | print (std::ostream &, const RegisterDictionaryPtr ®Dict) const |
| Print detailed information about this calling convention. | |
 Public Member Functions inherited from Sawyer::SharedObject | |
| SharedObject () | |
| Default constructor. | |
| SharedObject (const SharedObject &) | |
| Copy constructor. | |
| virtual | ~SharedObject () |
| Virtual destructor. | |
| SharedObject & | operator= (const SharedObject &) |
| Assignment. | |
Protected Member Functions | |
| template<class S > | |
| void | serialize (S &, unsigned) |
| Definition () | |
| Default constructor. | |
) and is a single word. The comment | |
Construct a new calling convention. The name of the calling convention usually comes from the documentation (see is a more complete name for the convention perhaps including the operating system and architecture but not containing line termination. | |
| Definition (const std::string &name, const std::string &comment, const Architecture::BaseConstPtr &) | |
| Property: Architecture with which this definition is associated. | |
| ~Definition () | |
| Property: Architecture with which this definition is associated. | |
| Architecture::BaseConstPtr | architecture () const |
| Property: Architecture with which this definition is associated. | |
| RegisterDictionaryPtr | registerDictionary () const |
| Property: Register dictionary for the architecture. | |
| const std::string & | name () const |
| Property: Short name of calling convention. | |
| void | name (const std::string &s) |
| Property: Architecture with which this definition is associated. | |
| static Ptr | instance (const std::string &name, const std::string &comment, const Architecture::BaseConstPtr &) |
| Allocating constructor. | |
Member Typedef Documentation
◆ Ptr
Reference counting pointer to calling convention definition.
Definition at line 33 of file Definition.h.
Constructor & Destructor Documentation
◆ Definition() [1/2]
|
protected |
Default constructor.
Constructs a new calling convention with no name or parameters.
◆ Definition() [2/2]
|
protected |
Property: Architecture with which this definition is associated.
Returns a non-null architecture from a weak pointer, aborting if the architecture has been deleted. Since Architecture objects contain a dictionary of all their calling conventions, the architecture's lifetime normally exceeds the lifetime of a calling convention definition and the weak pointer will be valid.
◆ ~Definition()
| Rose::BinaryAnalysis::CallingConvention::Definition::~Definition | ( | ) |
Property: Architecture with which this definition is associated.
Returns a non-null architecture from a weak pointer, aborting if the architecture has been deleted. Since Architecture objects contain a dictionary of all their calling conventions, the architecture's lifetime normally exceeds the lifetime of a calling convention definition and the weak pointer will be valid.
Member Function Documentation
◆ architecture()
| Architecture::BaseConstPtr Rose::BinaryAnalysis::CallingConvention::Definition::architecture | ( | ) | const |
Property: Architecture with which this definition is associated.
Returns a non-null architecture from a weak pointer, aborting if the architecture has been deleted. Since Architecture objects contain a dictionary of all their calling conventions, the architecture's lifetime normally exceeds the lifetime of a calling convention definition and the weak pointer will be valid.
◆ registerDictionary()
| RegisterDictionaryPtr Rose::BinaryAnalysis::CallingConvention::Definition::registerDictionary | ( | ) | const |
Property: Register dictionary for the architecture.
This property is read-only, set by the constructor. The register dictionary is not null.
◆ name() [1/2]
|
inline |
Property: Short name of calling convention.
Standard calling conventions have documented names, like "stdcall" and that's what should appear here. They're usually a single word. It is not necessary to include information like compiler, OS, wordsize, etc. Instead, the calling convention dictionary will have more than one convention named "stdcall" for the various architectures, one for x86 32-bit, another for x86-64, etc. Also, the comment property can contain a more complete name.
Definition at line 114 of file Definition.h.
◆ name() [2/2]
|
inline |
Property: Architecture with which this definition is associated.
Returns a non-null architecture from a weak pointer, aborting if the architecture has been deleted. Since Architecture objects contain a dictionary of all their calling conventions, the architecture's lifetime normally exceeds the lifetime of a calling convention definition and the weak pointer will be valid.
Definition at line 115 of file Definition.h.
◆ comment() [1/2]
|
inline |
Property: Full name of calling convention.
Whereas the Naming tips property contains a single-word name, this property contains the full name of the calling convention. The full name may include an operating system, compiler, architecture, word-size etc. It should not contain any line termination.
Definition at line 125 of file Definition.h.
◆ comment() [2/2]
|
inline |
Property: Full name of calling convention.
Whereas the Naming tips property contains a single-word name, this property contains the full name of the calling convention. The full name may include an operating system, compiler, architecture, word-size etc. It should not contain any line termination.
Definition at line 126 of file Definition.h.
◆ bitsPerWord() [1/2]
| size_t Rose::BinaryAnalysis::CallingConvention::Definition::bitsPerWord | ( | ) | const |
Property: Word size in bits.
This is the natural width of a word measured in bits. The value is positive and usually a multiple of eight.
If this property has no value, then it defaults to the word size of the architecture.
◆ bitsPerWord() [2/2]
| void Rose::BinaryAnalysis::CallingConvention::Definition::bitsPerWord | ( | const Sawyer::Optional< size_t > & | ) |
Property: Word size in bits.
This is the natural width of a word measured in bits. The value is positive and usually a multiple of eight.
If this property has no value, then it defaults to the word size of the architecture.
◆ nonParameterInputs() [1/2]
|
inline |
Non-parameter inputs.
This is the list of all allowed inputs that are not function parameters. For instance, things like the instruction pointer which the caller initializes to be the entry point of the function, or the x86 direction flag "df" which is normally set by the caller but not considered a function argument.
Definition at line 147 of file Definition.h.
◆ nonParameterInputs() [2/2]
|
inline |
Non-parameter inputs.
This is the list of all allowed inputs that are not function parameters. For instance, things like the instruction pointer which the caller initializes to be the entry point of the function, or the x86 direction flag "df" which is normally set by the caller but not considered a function argument.
Definition at line 148 of file Definition.h.
◆ clearParameters()
|
inline |
Erase all parameters.
Removes all input parameters, output parameters, and object pointer parameter.
Definition at line 154 of file Definition.h.
References clearInputParameters(), and clearOutputParameters().
◆ inputParameters()
|
inline |
Property: Enumerated input parameters.
Returns the vector of input (and in-out) parameters that have been enumerated; does not include implied stack parameters. This property is read-only; see also appendInputParameter and clearInputParameters.
Definition at line 165 of file Definition.h.
◆ inputRegisterParts()
| RegisterParts Rose::BinaryAnalysis::CallingConvention::Definition::inputRegisterParts | ( | ) | const |
Compute the set of input registers.
The returned list is all registers that might serve as function inputs, both function input parameters and non-parameter inputs.
◆ clearInputParameters()
|
inline |
Erase enumerated input parameters.
Removes all enumerated input parameters. In-out parameters, those input parameters that are also listed as outputs, are only removed from the input parameter list, effectively converting them to output-only parameters.
Definition at line 177 of file Definition.h.
Referenced by clearParameters().
◆ appendInputParameter() [1/4]
| void Rose::BinaryAnalysis::CallingConvention::Definition::appendInputParameter | ( | const ConcreteLocation & | ) |
Append input parameter.
This method appends a new parameter to the list of enumerated input or in-out parameters. Generally only non-stack parameters need to be enumerated since any parameter with a higher index is assumed to be located on the stack.
Referenced by appendInputParameter(), appendInputParameter(), and appendInputParameter().
◆ appendInputParameter() [2/4]
|
inline |
Append input parameter.
This method appends a new parameter to the list of enumerated input or in-out parameters. Generally only non-stack parameters need to be enumerated since any parameter with a higher index is assumed to be located on the stack.
Definition at line 186 of file Definition.h.
References appendInputParameter().
◆ appendInputParameter() [3/4]
|
inline |
Append input parameter.
This method appends a new parameter to the list of enumerated input or in-out parameters. Generally only non-stack parameters need to be enumerated since any parameter with a higher index is assumed to be located on the stack.
Definition at line 189 of file Definition.h.
References appendInputParameter().
◆ appendInputParameter() [4/4]
|
inline |
Append input parameter.
This method appends a new parameter to the list of enumerated input or in-out parameters. Generally only non-stack parameters need to be enumerated since any parameter with a higher index is assumed to be located on the stack.
Definition at line 192 of file Definition.h.
References appendInputParameter().
◆ outputParameters()
|
inline |
Property: List of output parameters.
Returns the vector of output (and in-out) parameters. This property is read-only; see also appendOutputParameter and clearOutputParameters.
Definition at line 201 of file Definition.h.
◆ clearOutputParameters()
|
inline |
Erase output parameters.
Removes all output parameters. In-out parameters, those output parameters that are also listed as inputs, are only removed from the output parameter list, effectively converting them to input-only parameters.
Definition at line 210 of file Definition.h.
Referenced by clearParameters().
◆ appendOutputParameter() [1/4]
| void Rose::BinaryAnalysis::CallingConvention::Definition::appendOutputParameter | ( | const ConcreteLocation & | ) |
Append output parameter.
This method appends a new output parameter. Output parameters may be the same as input parameters. For instance, if an input parameter is the EAX register then EAX can also be an output parameter, such as during a Linux system call where the input is the system call number and the output is the system call return value. Outputs written to the stack need not be enumerated in the calling convention dictionary.
Referenced by appendOutputParameter(), appendOutputParameter(), and appendOutputParameter().
◆ appendOutputParameter() [2/4]
|
inline |
Append output parameter.
This method appends a new output parameter. Output parameters may be the same as input parameters. For instance, if an input parameter is the EAX register then EAX can also be an output parameter, such as during a Linux system call where the input is the system call number and the output is the system call return value. Outputs written to the stack need not be enumerated in the calling convention dictionary.
Definition at line 221 of file Definition.h.
References appendOutputParameter().
◆ appendOutputParameter() [3/4]
|
inline |
Append output parameter.
This method appends a new output parameter. Output parameters may be the same as input parameters. For instance, if an input parameter is the EAX register then EAX can also be an output parameter, such as during a Linux system call where the input is the system call number and the output is the system call return value. Outputs written to the stack need not be enumerated in the calling convention dictionary.
Definition at line 224 of file Definition.h.
References appendOutputParameter().
◆ appendOutputParameter() [4/4]
|
inline |
Append output parameter.
This method appends a new output parameter. Output parameters may be the same as input parameters. For instance, if an input parameter is the EAX register then EAX can also be an output parameter, such as during a Linux system call where the input is the system call number and the output is the system call return value. Outputs written to the stack need not be enumerated in the calling convention dictionary.
Definition at line 227 of file Definition.h.
References appendOutputParameter().
◆ stackParameterOrder() [1/2]
|
inline |
Property: Stack parameter order.
Stack-based input parameters need not be enumerated. If N input parameters are enumerated, numbered 0 through N-1, then parameters N and above are assumed to be on the stack and are called the "implied stack parameters". This stackParameterOrder property describes whether a source code statement like function_call(a, b, c) pushes a first (LEFT_TO_RIGHT) or first (RIGHT_TO_LEFT).
If the enumerated input parameter list contains any stack parameters then implied stack parameters are not allowed.
Definition at line 242 of file Definition.h.
◆ stackParameterOrder() [2/2]
|
inline |
Property: Stack parameter order.
Stack-based input parameters need not be enumerated. If N input parameters are enumerated, numbered 0 through N-1, then parameters N and above are assumed to be on the stack and are called the "implied stack parameters". This stackParameterOrder property describes whether a source code statement like function_call(a, b, c) pushes a first (LEFT_TO_RIGHT) or first (RIGHT_TO_LEFT).
If the enumerated input parameter list contains any stack parameters then implied stack parameters are not allowed.
Definition at line 243 of file Definition.h.
◆ stackPointerRegister() [1/2]
| RegisterDescriptor Rose::BinaryAnalysis::CallingConvention::Definition::stackPointerRegister | ( | ) | const |
Property: Register for implied stack parameters.
This property holds the register that should be used for implied stack parameters. For instance, on 32-bit x86 this is probably ESP, where the base address is the ESP value immediately after the call instruction.
The value of this property defaults to the stack pointer register for the architecture. Setting the property to an empty register descriptor causes the default value from the architecture to be used instead.
◆ stackPointerRegister() [2/2]
| void Rose::BinaryAnalysis::CallingConvention::Definition::stackPointerRegister | ( | RegisterDescriptor | ) |
Property: Register for implied stack parameters.
This property holds the register that should be used for implied stack parameters. For instance, on 32-bit x86 this is probably ESP, where the base address is the ESP value immediately after the call instruction.
The value of this property defaults to the stack pointer register for the architecture. Setting the property to an empty register descriptor causes the default value from the architecture to be used instead.
◆ nonParameterStackSize() [1/2]
|
inline |
Property: Size of non-parameter stack area.
This is the size in bytes of the final non-parameter information pushed onto the stack by the function call instruction. For instance, the 32-bit x86 call instruction pushes a 4-byte return address, but some architectures use a link register instead, pushing nothing onto the stack.
Definition at line 266 of file Definition.h.
◆ nonParameterStackSize() [2/2]
|
inline |
Property: Size of non-parameter stack area.
This is the size in bytes of the final non-parameter information pushed onto the stack by the function call instruction. For instance, the 32-bit x86 call instruction pushes a 4-byte return address, but some architectures use a link register instead, pushing nothing onto the stack.
Definition at line 269 of file Definition.h.
◆ stackDirection() [1/2]
|
inline |
Property: Direction that stack grows for a push operation.
Most stacks grow downward for each push operation, so down is the default. Some odd architecture might grow up instead. In either case, it is assumed that the stack pointer is pointing to the last item pushed rather than one past the last item.
Definition at line 281 of file Definition.h.
◆ stackDirection() [2/2]
|
inline |
Property: Direction that stack grows for a push operation.
Most stacks grow downward for each push operation, so down is the default. Some odd architecture might grow up instead. In either case, it is assumed that the stack pointer is pointing to the last item pushed rather than one past the last item.
Definition at line 282 of file Definition.h.
◆ byteOrder()
| ByteOrder::Endianness Rose::BinaryAnalysis::CallingConvention::Definition::byteOrder | ( | ) | const |
Property: Order of bytes for multi-byte values in memory.
This property is read only. It's value comes from the architecture set by the constructor.
◆ stackCleanup() [1/2]
|
inline |
Property: Who pops stack parameters.
This property indicates whether the caller is responsible for popping stack parameters, or whether the called function is responsible for popping stack parameters. In either case, the non-parameter stack area (usually a return address) is popped by the called function.
Definition at line 297 of file Definition.h.
◆ stackCleanup() [2/2]
|
inline |
Property: Who pops stack parameters.
This property indicates whether the caller is responsible for popping stack parameters, or whether the called function is responsible for popping stack parameters. In either case, the non-parameter stack area (usually a return address) is popped by the called function.
Definition at line 298 of file Definition.h.
◆ stackAlignment() [1/2]
| const Alignment & Rose::BinaryAnalysis::CallingConvention::Definition::stackAlignment | ( | ) | const |
Property: Stack alignment.
This is the stack alignment measured in bytes for the stack pointer before the caller pushes any non-parameters (e.g., return address) or parameters.
◆ stackAlignment() [2/2]
| void Rose::BinaryAnalysis::CallingConvention::Definition::stackAlignment | ( | const Alignment & | ) |
Property: Stack alignment.
This is the stack alignment measured in bytes for the stack pointer before the caller pushes any non-parameters (e.g., return address) or parameters.
◆ thisParameter() [1/5]
|
inline |
Property: Object pointer parameter.
Object oriented code has method calls that are usually implemented as functions that take an extra parameter that isn't always explicitly listed in the high-level source code. This property describes where the object pointer is located and should not be included in the list of input parameters. The reason for not including it in the list of input parameters is because of the rule that implicit input parameter are allowed only if there are no explicit stack-based input parameters, and we want to be able to support having a stack-based object pointer along with implicit input parameters.
It is permissible for an object method to not list its object pointer as an object pointer, but rather treat it as a normal explicit or implicit input parameter. Doing so will make the calling convention look like its a plain function rather than an object method.
Definition at line 325 of file Definition.h.
Referenced by thisParameter(), thisParameter(), and thisParameter().
◆ thisParameter() [2/5]
|
inline |
Property: Object pointer parameter.
Object oriented code has method calls that are usually implemented as functions that take an extra parameter that isn't always explicitly listed in the high-level source code. This property describes where the object pointer is located and should not be included in the list of input parameters. The reason for not including it in the list of input parameters is because of the rule that implicit input parameter are allowed only if there are no explicit stack-based input parameters, and we want to be able to support having a stack-based object pointer along with implicit input parameters.
It is permissible for an object method to not list its object pointer as an object pointer, but rather treat it as a normal explicit or implicit input parameter. Doing so will make the calling convention look like its a plain function rather than an object method.
Definition at line 326 of file Definition.h.
◆ thisParameter() [3/5]
|
inline |
Property: Object pointer parameter.
Object oriented code has method calls that are usually implemented as functions that take an extra parameter that isn't always explicitly listed in the high-level source code. This property describes where the object pointer is located and should not be included in the list of input parameters. The reason for not including it in the list of input parameters is because of the rule that implicit input parameter are allowed only if there are no explicit stack-based input parameters, and we want to be able to support having a stack-based object pointer along with implicit input parameters.
It is permissible for an object method to not list its object pointer as an object pointer, but rather treat it as a normal explicit or implicit input parameter. Doing so will make the calling convention look like its a plain function rather than an object method.
Definition at line 327 of file Definition.h.
References thisParameter().
◆ thisParameter() [4/5]
|
inline |
Property: Object pointer parameter.
Object oriented code has method calls that are usually implemented as functions that take an extra parameter that isn't always explicitly listed in the high-level source code. This property describes where the object pointer is located and should not be included in the list of input parameters. The reason for not including it in the list of input parameters is because of the rule that implicit input parameter are allowed only if there are no explicit stack-based input parameters, and we want to be able to support having a stack-based object pointer along with implicit input parameters.
It is permissible for an object method to not list its object pointer as an object pointer, but rather treat it as a normal explicit or implicit input parameter. Doing so will make the calling convention look like its a plain function rather than an object method.
Definition at line 330 of file Definition.h.
References thisParameter().
◆ thisParameter() [5/5]
|
inline |
Property: Object pointer parameter.
Object oriented code has method calls that are usually implemented as functions that take an extra parameter that isn't always explicitly listed in the high-level source code. This property describes where the object pointer is located and should not be included in the list of input parameters. The reason for not including it in the list of input parameters is because of the rule that implicit input parameter are allowed only if there are no explicit stack-based input parameters, and we want to be able to support having a stack-based object pointer along with implicit input parameters.
It is permissible for an object method to not list its object pointer as an object pointer, but rather treat it as a normal explicit or implicit input parameter. Doing so will make the calling convention look like its a plain function rather than an object method.
Definition at line 333 of file Definition.h.
References thisParameter().
◆ returnAddressLocation() [1/2]
|
inline |
Property: Location of return address.
This property stores the location where the function return address is stored. I.e., the location contains the address to which this function returns after being called.
Definition at line 344 of file Definition.h.
◆ returnAddressLocation() [2/2]
|
inline |
Property: Location of return address.
This property stores the location where the function return address is stored. I.e., the location contains the address to which this function returns after being called.
Definition at line 345 of file Definition.h.
◆ instructionPointerRegister() [1/2]
|
inline |
Property: Register that points to next instruction to execute.
Definition at line 351 of file Definition.h.
◆ instructionPointerRegister() [2/2]
|
inline |
Property: Register that points to next instruction to execute.
Definition at line 352 of file Definition.h.
◆ calleeSavedRegisters() [1/2]
|
inline |
Property: Callee-saved registers.
This is the set of registers that the called function must preserve across the call, either by not modifying them or by saving and then restoring them. Registers that are used to return values should obviously not be listed here since they need to be modified in order to return a value.
Registers that are not restored but which are also not listed as output parameters (return values) are assumed to be scratch registers. Status flags are typically in this category, as are the stack pointer and instruction pointer. Most calling conventions have at least a few general purpose registers that can be used as scratch space.
Definition at line 366 of file Definition.h.
◆ calleeSavedRegisters() [2/2]
|
inline |
Property: Callee-saved registers.
This is the set of registers that the called function must preserve across the call, either by not modifying them or by saving and then restoring them. Registers that are used to return values should obviously not be listed here since they need to be modified in order to return a value.
Registers that are not restored but which are also not listed as output parameters (return values) are assumed to be scratch registers. Status flags are typically in this category, as are the stack pointer and instruction pointer. Most calling conventions have at least a few general purpose registers that can be used as scratch space.
Definition at line 367 of file Definition.h.
◆ scratchRegisters() [1/2]
|
inline |
Property: Scratch registers.
This is the set of registers that are not parameters or return values but which are nonetheless can be modified and not restored by the called function. These are also known as caller-saved registers since the caller must save and restore the value across the call if necessary.
Definition at line 380 of file Definition.h.
◆ scratchRegisters() [2/2]
|
inline |
Property: Scratch registers.
This is the set of registers that are not parameters or return values but which are nonetheless can be modified and not restored by the called function. These are also known as caller-saved registers since the caller must save and restore the value across the call if necessary.
Definition at line 381 of file Definition.h.
◆ getUsedRegisterParts()
| RegisterParts Rose::BinaryAnalysis::CallingConvention::Definition::getUsedRegisterParts | ( | ) | const |
Returns all registers mentioned in this definition.
The registers are returned as a RegisterParts, which tracks which bits of registers are present but not which individual registers were inserted into the container. For instance, if x86 AX is inserted first, then inserting the overlapping AL and AH registers is a no-op since their bits are already present.
The return value does not include registers that are incidental to a parameter's location. For instance, the stack pointer register is not included in this list unless its listed as a return register, callee-saved register, or scratch register.
◆ returnValueAllocator() [1/2]
| AllocatorPtr Rose::BinaryAnalysis::CallingConvention::Definition::returnValueAllocator | ( | ) | const |
Property: Allocator for return values.
Describes where/how return the value(s) are stored.
◆ returnValueAllocator() [2/2]
| void Rose::BinaryAnalysis::CallingConvention::Definition::returnValueAllocator | ( | const AllocatorPtr & | ) |
Property: Allocator for return values.
Describes where/how return the value(s) are stored.
◆ argumentValueAllocator() [1/2]
| AllocatorPtr Rose::BinaryAnalysis::CallingConvention::Definition::argumentValueAllocator | ( | ) | const |
Property: Allocator for argument values.
Describe where/how function arguments are stored.
◆ argumentValueAllocator() [2/2]
| void Rose::BinaryAnalysis::CallingConvention::Definition::argumentValueAllocator | ( | const AllocatorPtr & | ) |
Property: Allocator for argument values.
Describe where/how function arguments are stored.
◆ print() [1/2]
| void Rose::BinaryAnalysis::CallingConvention::Definition::print | ( | std::ostream & | ) | const |
Print detailed information about this calling convention.
If a register dictionary is supplied then that dictionary is used instead of any dictionary already attached to this definition. This feature is mostly for backward compatibility.
◆ print() [2/2]
| void Rose::BinaryAnalysis::CallingConvention::Definition::print | ( | std::ostream & | , |
| const RegisterDictionaryPtr & | regDict | ||
| ) | const |
Print detailed information about this calling convention.
If a register dictionary is supplied then that dictionary is used instead of any dictionary already attached to this definition. This feature is mostly for backward compatibility.
The documentation for this class was generated from the following file:
