Home/Instructions/Landing Pad
LPAD

RISC-V LPAD Instruction Details

Instruction ManualU-type (AUIPC HINT)

Zicfilp landing-pad instruction; validates indirect jump/call targets when forward-edge CFI is enabled.

Instruction Syntax

lpad label

RV32/RV64 Zicfilp (depends on Zicsr); syntax lpad label, with a 20-bit LPL from 0 through 1048575, not a PC-relative offset.

32-bit U-type: LPL=bits31:12, rd=00000, AUIPC opcode=0010111; there is no general-register destination operand.

Only xLPE=1 and ELP=LP_EXPECTED checks four-byte PC alignment and matching nonzero LPL against x7[31:12]; success clears ELP, otherwise software-check (cause=18, xtval=2).

With xLPE=0 or ELP=NO_LP_EXPECTED this is a no-op; trap entry separately saves old ELP to xPELP and clears ELP.

ZicfilpSecurity Mechanisms

Instruction Behavior

With Zicfilp enabled, JALR/C.JR/C.JALR requires a landing pad when rs1 is not x1, x5, or x7. With ELP=LP_EXPECTED, the next instruction must be a 4-byte-aligned LPAD; a nonzero 20-bit LPL must match x7[31:12], or a software-check exception occurs (cause=18, xtval=2). Success sets ELP=NO_LP_EXPECTED; LPAD is a no-op when disabled or no landing pad is expected.

LPAD Decode & Execute Animation

Shows only specification-defined encodings, conditions, and architectural state; it does not model pipelines, cache coherence, or platform policy.

lpad 0x12345
Execution Context
Instruction Encoding
31..12
LPL
00010010001101000101
11..7
rd
00000 (x0)
6..0
opcode
0010111 (AUIPC)
Decode fixed fields
Fixed encoding fields identify the instruction and operand roles.
No exception: ELP is updated to NO_LP_EXPECTED.
Architectural state has not been committed.

Quick Understanding & Search Notes

LPAD belongs to the RISC-V Zicfilp forward-edge CFI instructions; behavior depends on whether Zicfilp is enabled and on environment configuration.

LPAD uses AUIPC HINT code points and has no architectural effect when inactive.
LPAD uses the U-type AUIPC major opcode with rd fixed to x0; its LPL occupies bits 31:12.

Common Usage Scenarios

Forward-edge CFI

Assume RV64 Zicfilp enabled, ELP=LP_EXPECTED and PC=0x2000; lpad 0 skips label matching and sets ELP=NO_LP_EXPECTED.

Indirect call/jump marking

Assume RV64 Zicfilp enabled, ELP=LP_EXPECTED and PC=0x2000; lpad 0 skips label matching and sets ELP=NO_LP_EXPECTED.

Security hardening

Assume RV64 Zicfilp enabled, ELP=LP_EXPECTED and PC=0x2000; lpad 0 skips label matching and sets ELP=NO_LP_EXPECTED.

Pre-Use Checklist

Syntax Check
  • RV32/RV64 Zicfilp (depends on Zicsr); syntax lpad label, with a 20-bit LPL from 0 through 1048575, not a PC-relative offset.
  • 32-bit U-type: LPL=bits31:12, rd=00000, AUIPC opcode=0010111; there is no general-register destination operand.
Semantic Check
  • Only xLPE=1 and ELP=LP_EXPECTED checks four-byte PC alignment and matching nonzero LPL against x7[31:12]; success clears ELP, otherwise software-check (cause=18, xtval=2).
  • With xLPE=0 or ELP=NO_LP_EXPECTED this is a no-op; trap entry separately saves old ELP to xPELP and clears ELP.

Pitfalls / Common Confusions

PC alignment and label checks apply only with Zicfilp enabled and ELP=LP_EXPECTED.
LPL=0 skips label matching; a nonzero LPL compares x7[31:12], not the entire x7.
Trap entry saves the previous ELP in xPELP and clears ELP to NO_LP_EXPECTED.

FAQ

What happens if the related CFI feature is inactive for LPAD?

LPAD executes as a no-op.

Which indirect branches do not require LPAD?

JALR/C.JR/C.JALR with rs1=x1, x5, or x7 does not set ELP=LP_EXPECTED; the x7 form is a software guarded branch.