In the standard ABI, procedures should not modify the integer registers tp and gp, because signal handlers may rely upon their values.

The presence of a frame pointer is optional. If a frame pointer exists, it must reside in x8 (s0); the register remains callee-saved.

If a platform requires use of a dedicated general-purpose register for a platform-specific purpose, it is recommended to use gp (x3). The platform ABI specification must document the use of this register. For such platforms, care must be taken to ensure all code (compiler generated or otherwise) avoids using gp in a way incompatible with the platform specific purpose, and that global pointer relaxation is disabled in the toolchain.

The presence of a frame pointer is optional. If a frame pointer exists, it must reside in x8 (s0); the register remains callee-saved.

Code that uses a frame pointer will construct a linked list of stack frames, where each frame links to its caller using a "frame record". A frame record consists of two XLEN values on the stack; the return address and the link to the next frame record. The frame pointer register will point to the innermost frame, thereby starting the linked list. By convention, the lowest XLEN value shall point to the previous frame, while the next XLEN value shall be the return address. The end of the frame record chain is indicated by the address zero appearing as the next link in the chain.

After the prologue, the frame pointer register will point to the Canonical Frame Address or CFA, which is the stack pointer value on entry to the current procedure. The previous frame pointer and return address pair will reside just prior to the current stack address held in fp. This puts the return address at fp - XLEN/8, and the previous frame pointer at fp - 2 * XLEN/8.

It is left to the platform to determine the level of conformance with this convention. A platform may choose:

*: Floating-point values in callee-saved registers are only preserved across calls if they are no larger than the width of a floating-point register in the targeted ABI. Therefore, these registers can always be considered temporaries if targeting the base integer calling convention.

The Floating-Point Control and Status Register (fcsr) must have thread storage duration in accordance with C11 section 7.6 "Floating-point environment <fenv.h>".

The base integer calling convention provides eight argument registers, a0-a7, the first two of which are also used to return values.

Scalars that are at most XLEN bits wide are passed in a single argument register, or on the stack by value if none is available. When passed in registers or on the stack, integer scalars narrower than XLEN bits are widened according to the sign of their type up to 32 bits, then sign-extended to XLEN bits. When passed in registers or on the stack, floating-point types narrower than XLEN bits are widened to XLEN bits, with the upper bits undefined.

Scalars that are 2×XLEN bits wide are passed in a pair of argument registers, with the low-order XLEN bits in the lower-numbered register and the high-order XLEN bits in the higher-numbered register. If no argument registers are available, the scalar is passed on the stack by value. If exactly one register is available, the low-order XLEN bits are passed in the register and the high-order XLEN bits are passed on the stack.

Scalars wider than 2×XLEN bits are passed by reference and are replaced in the argument list with the address.

Aggregates whose total size is no more than XLEN bits are passed in a register, with the fields laid out as though they were passed in memory. If no register is available, the aggregate is passed on the stack. Aggregates whose total size is no more than 2×XLEN bits are passed in a pair of registers; if only one register is available, the first XLEN bits are passed in a register and the remaining bits are passed on the stack. If no registers are available, the aggregate is passed on the stack. Bits unused due to padding, and bits past the end of an aggregate whose size in bits is not divisible by XLEN, are undefined.

Aggregates or scalars passed on the stack are aligned to the greater of the type alignment and XLEN bits, but never more than the stack alignment.

Aggregates larger than 2×XLEN bits are passed by reference and are replaced in the argument list with the address, as are C++ aggregates with nontrivial copy constructors, destructors, or vtables.

Fixed-length vectors are treated as aggregates.

Empty structs or union arguments or return values are ignored by C compilers which support them as a non-standard extension. This is not the case for C++, which requires them to be sized types.

Arguments passed by reference may be modified by the callee.

Floating-point reals are passed the same way as aggregates of the same size; complex floating-point numbers are passed the same way as a struct containing two floating-point reals. (This constraint changes when the integer calling convention is augmented by the hardware floating-point calling convention.)

In the base integer calling convention, variadic arguments are passed in the same manner as named arguments, with one exception. Variadic arguments with 2×XLEN-bit alignment and size at most 2×XLEN bits are passed in an aligned register pair (i.e., the first register in the pair is even-numbered), or on the stack by value if none is available. After a variadic argument has been passed on the stack, all future arguments will also be passed on the stack (i.e. the last argument register may be left unused due to the aligned register pair rule).

Values are returned in the same manner as a first named argument of the same type would be passed. If such an argument would have been passed by reference, the caller allocates memory for the return value, and passes the address as an implicit first parameter.

The stack grows downwards (towards lower addresses) and the stack pointer shall be aligned to a 128-bit boundary upon procedure entry. The first argument passed on the stack is located at offset zero of the stack pointer on function entry; following arguments are stored at correspondingly higher addresses.

In the standard ABI, the stack pointer must remain aligned throughout procedure execution. Non-standard ABI code must realign the stack pointer prior to invoking standard ABI procedures. The operating system must realign the stack pointer prior to invoking a signal handler; hence, POSIX signal handlers need not realign the stack pointer. In systems that service interrupts using the interruptee’s stack, the interrupt service routine must realign the stack pointer if linked with any code that uses a non-standard stack-alignment discipline, but need not realign the stack pointer if all code adheres to the standard ABI.

Procedures must not rely upon the persistence of stack-allocated data whose addresses lie below the stack pointer.

Registers s0-s11 shall be preserved across procedure calls. No floating-point registers, if present, are preserved across calls. (This property changes when the integer calling convention is augmented by the hardware floating-point calling convention.)

The hardware floating-point calling convention adds eight floating-point argument registers, fa0-fa7, the first two of which are also used to return values. Values are passed in floating-point registers whenever possible, whether or not the integer registers have been exhausted.

The remainder of this section applies only to named arguments. Variadic arguments are passed according to the integer calling convention.

ABI_FLEN refers to the width of a floating-point register in the ABI. The ABI_FLEN must be no wider than the ISA’s FLEN. The ISA might have wider floating-point registers than the ABI.

For the purposes of this section, "struct" refers to a C struct with its hierarchy flattened, including any array fields. That is, struct { struct { float f[1]; } a[2]; } and struct { float f0; float f1; } are treated the same. Fields containing empty structs or unions are ignored while flattening, even in C++, unless they have nontrivial copy constructors or destructors. Fields containing zero-length bit-fields or zero-length arrays are ignored while flattening. Attributes such as aligned or packed do not interfere with a struct’s eligibility for being passed in registers according to the rules below, i.e. struct { int i; double d; } and struct __attribute__((__packed__)) { int i; double d } are treated the same, as are struct { float f; float g; } and struct { float f; float g __attribute__ ((aligned (8))); }.

A real floating-point argument is passed in a floating-point argument register if it is no more than ABI_FLEN bits wide and at least one floating-point argument register is available. Otherwise, it is passed according to the integer calling convention. When a floating-point argument narrower than FLEN bits is passed in a floating-point register, it is 1-extended (NaN-boxed) to FLEN bits.

A struct containing just one floating-point real is passed as though it were a standalone floating-point real.

A struct containing two floating-point reals is passed in two floating-point registers, if neither real is more than ABI_FLEN bits wide and at least two floating-point argument registers are available. (The registers need not be an aligned pair and are assigned to the two reals in memory order.) Otherwise, it is passed according to the integer calling convention.

A complex floating-point number, or a struct containing just one complex floating-point number, is passed as though it were a struct containing two floating-point reals.

A struct containing one floating-point real and one integer (or bitfield), in either order, is passed in a floating-point register and an integer register, provided the floating-point real is no more than ABI_FLEN bits wide and the integer is no more than XLEN bits wide, and at least one floating-point argument register and at least one integer argument register is available. If the struct is passed in this manner, and the integer is narrower than XLEN bits, the remaining bits are unspecified. If the struct is not passed in this manner, then it is passed according to the integer calling convention.

Unions are never flattened and are always passed according to the integer calling convention.

Values are returned in the same manner as a first named argument of the same type would be passed.

Floating-point registers fs0-fs11 shall be preserved across procedure calls, provided they hold values no more than ABI_FLEN bits wide.

The RISC-V V Vector Extension[riscv-v-extension] defines a set of thirty-two vector registers, v0-v31. The RISC-V Vector Extension Intrinsic Document[rvv-intrinsic-doc] defines vector types which include vector mask types, vector data types, and tuple vector data types. A value of vector type can be stored in vector register groups.

The remainder of this section applies only to named vector arguments, other named arguments and return values follow the standard calling convention. Variadic vector arguments are passed by reference.

v0 is used to pass the first vector mask argument to a function, and to return vector mask result from a function. v8-v23 are used to pass vector data arguments, tuple vector data arguments and the rest vector mask arguments to a function, and to return vector data and vector tuple results from a function.

It must ensure that the entire contents of v1-v7 and v24-v31 are preserved across the call.

Each vector data type and vector tuple type has an LMUL attribute that indicates a vector register group. The value of LMUL indicates the number of vector registers in the vector register group and requires the first vector register number in the vector register group must be a multiple of it. For example, the LMUL of vint64m8_t is 8, so v8-v15 vector register group can be allocated to this type, but v9-v16 can not because the v9 register number is not a multiple of 8. If LMUL is less than 1, it is treated as 1. If it is a vector mask type, its LMUL is 1.

Each vector tuple type also has an NFIELDS attribute that indicates how many vector register groups the type contains. Thus a vector tuple type needs to take up LMUL×NFIELDS registers.

The rules for passing vector arguments are as follows:

Vector values are returned in the same manner as the first named argument of the same type would be passed.

Vector types are disallowed in struct or union.

Vector arguments and return values are disallowed to pass to an unprototyped function.

The ILP32E calling convention is designed to be usable with the RV32E ISA. This calling convention is the same as the integer calling convention, except for the following differences. The stack pointer need only be aligned to a 32-bit boundary. Registers x16-x31 do not participate in the calling convention, so there are only six argument registers, a0-a5, only two callee-saved registers, s0-s1, and only three temporaries, t0-t2.

If used with an ISA that has any of the registers x16-x31 and f0-f31, then these registers are considered temporaries.

The ILP32E calling convention is not compatible with ISAs that have registers that require load and store alignments of more than 32 bits. In particular, this calling convention must not be used with the D ISA extension.

The RV64ILP32* calling convention is designed to be usable with the RV64* ISA. These calling conventions are composed of the integer & floating-point & vector calling conventions. When passed in registers or on the stack, pointer scalars (32-bit), narrower than XLEN bits (64-bit), are sign-extended to XLEN bits.

This specification defines the following named ABIs:

The LP64* ABIs are only compatible with RV64* ISAs. The ILP32* are compatible with RV32* and RV64* ISAs.

The *F ABIs require the *F ISA extension, the *D ABIs require the *D ISA extension, and the LP64Q ABI requires the Q ISA extension.

While various different ABIs are technically possible, for software compatibility reasons it is strongly recommended to use the following default ABIs for specific architectures:

There are two conventions for C/C++ type sizes and alignments.

The alignment of max_align_t is 16.

CHAR_BIT is 8.

Structs and unions are aligned to the alignment of their most strictly aligned member. The size of any object is a multiple of its alignment.

Various compilers have support for fixed-length vector types, for example GCC and Clang both support declaring a type with __attribute__((vector_size(N)), where N is a positive number larger than zero.

The alignment requirement for the fixed length vector shall be equivalent to the alignment requirement of its elemental type.

The size of the fixed length vector is determined by multiplying the size of its elemental type by the total number of elements within the vector.

char is unsigned.

Booleans (bool/_Bool) stored in memory or when being passed as scalar arguments are either 0 (false) or 1 (true).

A null pointer (for all types) has the value zero.

_Float16 is as defined in the C ISO/IEC TS 18661-3 extension.

__bf16 has the same parameter passing and return rules as for _Float16.

_Complex types have the same layout as a struct containing two fields of the corresponding real type (float, double, or long double), with the first member holding the real part and the second member holding the imaginary part.

The type size_t is defined as unsigned int for RV32 and unsigned long for RV64.

The type ptrdiff_t is defined as int for RV32 and long for RV64.

Bit-fields are packed in little-endian fashion. A bit-field that would span the alignment boundary of its integer type is padded to begin at the next alignment boundary. For example, struct { int x : 10; int y : 12; } is a 32-bit type with x in bits 9-0, y in bits 21-10, and bits 31-22 undefined. By contrast, struct { short x : 10; short y : 12; } is a 32-bit type with x in bits 9-0, y in bits 27-16, and bits 31-28 and bits 15-10 undefined.

Bit-fields which are larger than their integer types are only present in C++ and are defined by the Itanium C++ ABI [itanium-cxx-abi]. The bit-field and containing struct are aligned on a boundary corresponding to the largest integral type smaller than the bit-field, up to 64-bit alignment on RV32 or 128-bit alignment on RV64. Any bits in excess of the size of the declared type are treated as padding. For example struct { char x : 9; char y; } is a 24-bit type with x in bits 7-0, y in bit 23-16, and bits 15-8 undefined; struct { char x : 9; char y : 2 } is a 16-bit type with x in bits 7-0, y in bit 10-9, and bits 8 and 15-11 undefined.

Unnamed nonzero length bit-fields allocate space in the same fashion as named bitfields but do not affect the alignment of the containing struct.

Zero length bit-fields are aligned relative to the start of the containing struct according to their declared type and, since they must be unnamed, do not affect the struct alignment. C requires bit-fields on opposite sides of a zero-length bitfield to be treated as separate memory locations for the purposes of data races.

The va_list type has the same representation as void* and points to a sequence of zero or more arguments with preceding padding for alignment, formatted and aligned as variadic arguments passed on the stack according to the integer calling convention (Section 2.1). All standard calling conventions use the same representation for variadic arguments to allow va_list types to be shared between them.

The va_start macro in a function initializes its va_list argument to point to the first address at which a variadic argument could be passed to the function. If all integer argument registers are used for named formal arguments, the first variadic argument will have been passed on the stack by the caller, and the va_list can point to the address immediately after the last named argument passed on the stack, or the sp value on entry if no named arguments were passed on the stack. If some integer argument registers were not used for named formal arguments, then the first variadic argument may have been passed in a register. The function is then expected to construct a varargs save area immediately below the entry sp and fill it with the entry values of all integer argument registers not used for named arguments, in sequence. The va_list value can then be initialized to the start of the varargs save area, and it will iterate through any variadic arguments passed via registers before continuing to variadic arguments passed on the stack, if any.

The va_arg macro will align its va_list argument, fetch a value, and increment the va_list according to the alignment and size of a variadic argument of the given type, which may not be the same as the alignment and size of the given type in memory. If the type is passed by reference, the size and alignment used will be those of a pointer, and the fetched pointer will be used as the address of the actual argument. The va_copy macro is a single pointer copy and the va_end macro performs no operation.

This section defines the sizes and alignments for the vector types defined in the RISC-V Vector Extension Intrinsic Document[rvv-intrinsic-doc]. The actual size of each type is determined by the hardware configuration, which is based on the content of the vlenb register.

There are three classes of vector types: the vector mask types, the vector data types and the vector tuple types.

The following definitions apply for all ABIs defined in this document. Here there is no differentiation between ILP32 and LP64 ABIs.

The following definitions apply for all ABIs defined in this document. Here there is no differentiation between ILP32 and LP64 ABIs.

wchar_t is signed. wint_t is unsigned.

The medium low code model, or medlow, allows the code to address the whole RV32 address space or the lower 2 GiB and highest 2 GiB of the RV64 address space (0xFFFFFFFF7FFFF800 ~ 0xFFFFFFFFFFFFFFFF and 0x0 ~ 0x000000007FFFF7FF). By using the lui and load / store instructions, when referring to an object, or addi, when calculating an address literal, for example, a 32-bit address literal can be produced.

The following instructions show how to load a value, store a value, or calculate an address in the medlow code model.

The medium any code model, or medany, allows the code to address the range between -2 GiB and +2 GiB from its position. By using auipc and load / store instructions, when referring to an object, or addi, when calculating an address literal, for example, a signed 32-bit offset, relative to the value of the pc register, can be produced.

As a special edge-case, undefined weak symbols must still be supported, whose addresses will be 0 and may be out of range depending on the address at which the code is linked. Any references to possibly-undefined weak symbols should be made indirectly through the GOT as is used for position-independent code. Not doing so is deprecated and a future version of this specification will require using the GOT, not just advise.

The following instructions show how to load a value, store a value, or calculate an address in the medany code model.

This model is similar to the medium any code model, but uses the global offset table (GOT) for non-local symbol addresses.

The large code model allows the code to address the whole RV64 address space. Thus, this model is only available for RV64. By putting object addresses into literal pools, a 64-bit address literal can be loaded from the pool.

This model also changes the function call patterns. An external function address must be loaded from a literal pool entry, and use jalr to jump to the target function.

The vector data types and vector mask types, as defined in the section Section 4.6, are treated as vendor-extended types in the Itanium C++ ABI [itanium-cxx-abi]. These mangled name for these types is "u"<len>"rvv_"<type-name>. Specifically, prefixing the type name with rvv_, which is prefixed by a decimal string indicating its length, which is prefixed by "u".

For example:

is mangled as

The section below lists the defined RISC-V-specific values for several ELF header fields; any fields not listed in this section have no RISC-V-specific values.

There are no RISC-V specific definitions relating to ELF string tables.

__global_pointer$ must be exported in the dynamic symbol table of dynamically-linked executables if there are any GP-relative accesses present in the executable.

RISC-V is a classical RISC architecture that has densely packed non-word sized instruction immediate values. While the linker can make relocations on arbitrary memory locations, many of the RISC-V relocations are designed for use with specific instructions or instruction sequences. RISC-V has several instruction specific encodings for PC-Relative address loading, jumps, branches and the RVC compressed instruction set.

The purpose of this section is to describe the RISC-V specific instruction sequences with their associated relocations in addition to the general purpose machine word sized relocations that are used for symbol addresses in the Global Offset Table or DWARF meta data.

Table 13 provides details of the RISC-V ELF relocations; the meaning of each column is given below:

This section and later ones contain fragments written in assembler. The precise assembler syntax, including that of the relocations, is described in the RISC-V Assembly Programmer’s Manual [rv-asm].

RISC-V adopts the ELF Thread Local Storage Model in which ELF objects define .tbss and .tdata sections and PT_TLS program headers that contain the TLS "initialization images" for new threads. The .tbss and .tdata sections are not referenced directly like regular segments, rather they are copied or allocated to the thread local storage space of newly created threads. See ELF Handling For Thread-Local Storage [tls].

In The ELF Thread Local Storage Model, TLS offsets are used instead of pointers. The ELF TLS sections are initialization images for the thread local variables of each new thread. A TLS offset defines an offset into the dynamic thread vector which is pointed to by the TCB (Thread Control Block). RISC-V uses Variant I as described by the ELF TLS specification, with tp containing the address one past the end of the TCB.

There are various thread local storage models for statically allocated or dynamically allocated thread local storage. Table 17 lists the thread local storage models:

The program linker in the case of static TLS or the dynamic linker in the case of dynamic TLS allocate TLS offsets for storage of thread local variables.