Informazioni di unwinding per la gestione delle eccezioni V3

Ambito

Unwind Information V3 aggiunge il supporto a Intel APX (Advanced Performance Extensions). Offre inoltre una maggiore flessibilità per la generazione di codice consentita sia nei prologhi di funzione che negli epiloghi, consentendo ai compilatori di ottimizzare meglio le funzioni nel suo complesso.

Unwind V3 è necessario per il codice che supporta APX. Il codice non abilitato per APX deve comunque usare le informazioni di rimozione convenzionali (pre-V3).

Terminologia

Layout generale del file oggetto

Unwind V3 riutilizza senza modificarle le convenzioni di sezione PE/COFF .pdata e .xdata esistenti:

.pdata   - sorted array of IMAGE_AMD64_RUNTIME_FUNCTION_ENTRY (12 bytes each)
.xdata   - UNWIND_INFO_V3 structures referenced by .pdata entries

Ogni RUNTIME_FUNCTION voce è:

Nessuna modifica da V1 o V2.

UNWIND_INFO_V3 Intestazione

Tutti i campi multi byte sono little-endian. Bit 0 è l'LSB di ogni byte.

Semantica dei campi

UNW_FLAG_LARGE e UNWIND_INFO_LARGE_V3

Quando UNW_FLAG_LARGE è impostato nell'intestazione Flags, il primo byte del payload è un'estensione a 1 byte UNWIND_INFO_LARGE_V3 :

SizeOfPrologHighByte viene combinato con UNWIND_INFO_V3.SizeOfProlog per formare una dimensione di prologo a 16 bit: SizeOfProlog16 = (SizeOfPrologHighByte << 8) | SizeOfProlog.

Inoltre, quando UNW_FLAG_LARGE è impostato:

• Le voci di offset IP prolog sono senza segno a 16 bit (2 byte ciascuno) anziché a 8 bit.

Il UNWIND_INFO_LARGE_V3 byte fa parte del payload ed è incluso in PayloadWords. La formula di offset dell'handler rimane invariata.

Questo flag è necessario solo per i prolog che superano i 255 byte.

Individuazione del gestore delle eccezioni / informazioni della catena

Identico a V1 o V2:

handler_offset = ALIGN_UP(sizeof(UNWIND_INFO_V3) + PayloadWords * 2, 4)

Se UNW_FLAG_EHANDLER o UNW_FLAG_UHANDLER è impostato, un'RVA a 4 byte del gestore si trova in handler_offset, seguita dai dati del gestore specifici del linguaggio.

Se UNW_FLAG_CHAININFO è impostato, un byte a 12 byte RUNTIME_FUNCTION si trova in handler_offset.

Layout del payload

Immediatamente dopo l'intestazione di 4 byte, il payload è organizzato nel seguente ordine (il tutto in formato packed, semantica #pragma pack(1)):

1. UNWIND_INFO_LARGE_V3 - 1 byte, presente solo se UNW_FLAG_LARGE è impostato.
2. Offset IP del prologo - NumberOfOps byte (o parole di 16 bit se UNW_FLAG_LARGE).
3. Per ogni epilogo (ripetuto NumberOfEpilogs volte):
   • EPILOG_INFO_V3 Descrittore.
   • EPILOG_INFO_EX_V3 o EPILOG_INFO_LARGE_EX_V3 descrittore esteso (presente solo quando NumberOfOps > 0).
   • Matrice di offset IP : NumberOfOps byte (o parole a 16 bit se EPILOG_INFO_LARGE).
4. Pool WOD: byte rimanenti.

Dimensione totale = PayloadWords × 2 byte (può includere riempimento per riempire le parole).

Offset IP di Prolog

Un array di elementi NumberOfOps. Ogni voce è un byte senza segno che indica l'offset IP dall'inizio del frammento di istruzione che esegue la corrispondente operazione di unwinding. Quando UNW_FLAG_LARGE è impostata, ogni voce è invece una word a 16 bit senza segno.

Ordine: Il primo elemento corrisponde all'operazione più vicina al corpo della funzione (l'ultima istruzione del prologo con un effetto di unwinding). L'ultima voce corrisponde all'operazione più vicina al punto di ingresso della funzione (la prima istruzione di prologo). Corrisponde alla convenzione V1 o V2 di elencare i codici di rimozione nell'ordine di esecuzione inversa. I WOD prologo iniziano sempre in corrispondenza dell'offset di byte zero del pool WOD e si applica lo stesso ordinamento.

Descrittori di epilogo

Zero o più strutture EPILOG_INFO_V3 seguono gli offset IP del prologo. Ognuno può avere un valore facoltativo EPILOG_INFO_EX_V3 (o EPILOG_INFO_LARGE_EX_V3 quando il EPILOG_INFO_LARGE flag è impostato) più la propria matrice di offset IP a dimensione variabile, di dimensioni NumberOfOps:

Quando NumberOfOps > 0 (descrittore completo)

Modulo standard (EPILOG_INFO_LARGE non impostato):

EPILOG_INFO_V3:

EPILOG_INFO_EX_V3:

Formato grande (EPILOG_INFO_LARGE impostato):

EPILOG_INFO_V3:

EPILOG_INFO_LARGE_EX_V3:

Quando NumberOfOps == 0 (descrittore ereditato)

EPILOG_INFO_V3:

Un EPILOG_INFO_V3 record con NumberOfOps == 0 eredita i valori effettivi per NumberOfOps, FirstOp, IpOffsetOfLastInstruction campi e matrice di offset IP dal primo oggetto precedente EPILOG_INFO_V3 con NumberOfOps != 0. Il compilatore deve garantire che Flags i bit 0 e 1 in un record di epilogo abbiano NumberOfOps == 0 lo stesso valore di quelli del primo EPILOG_INFO_V3 precedente con NumberOfOps != 0.

Semantica del campo Epilog

Offset IP di Epilog

Subito dopo ogni descrittore epilogo completo (quando NumberOfOps > 0), una matrice di NumberOfOps voci restituisce l'offset IP di ogni istruzione epiloga con un WOD corrispondente. Ogni voce è un byte senza segno o una parola senza segno a 16 bit quando EPILOG_INFO_LARGE viene impostata. Ordinamento: prima voce = operazione più vicina al corpo (prima istruzione dell'epilogo con un effetto di unwinding), ultima voce = operazione più vicina all'istruzione di trasferimento del controllo.

WOD Pool

I byte rimanenti nel payload formano il pool WOD. I WOD del prologo iniziano in modo implicito in corrispondenza dell'offset di byte 0 di questo pool. L'elenco WOD di ogni epilogo inizia in corrispondenza dell'offset di byte specificato dal relativo FirstOp campo. I WOD sono compressi senza allineamento o spaziatura interna tra di essi.

Il numero di WOD consumati per il prologo è UNWIND_INFO_V3.NumberOfOps. Il numero consumato per ciascun epilogo è quello del rispettivo EPILOG_INFO_V3.NumberOfOps (o quello ereditato).

Informazioni di riferimento sulla codifica WOD

I WOD sono a lunghezza variabile (1-5 byte), compressi con #pragma pack(1). Il codice operativo viene codificato nei bit di ordine minimo del primo byte. La decodifica richiede un'ispezione a più livelli.

Tabella di smistamento dei codici operativi

Per decodificare un WOD, leggere il primo byte e testarne i bit bassi nell'ordine seguente:

** Algoritmo di decodifica WOD (pseudocodice):**

uint8_t b0 = pool[offset];
uint8_t op3 = b0 & 0x07;

switch (op3)
{
case 4: return WOD_PUSH;           // 3-bit opcode = 100b
case 5: return WOD_SAVE_NONVOL_FAR;// 3-bit opcode = 101b
case 6: return WOD_SAVE_NONVOL;    // 3-bit opcode = 110b
case 7: return WOD_PUSH_CONSECUTIVE_2; // 3-bit opcode = 111b
default: break; // bits[2:0] are 0b000, 0b001, 0b010, or 0b011
}

uint8_t op4 = b0 & 0x0F;
switch (op4)
{
case 0x08: return WOD_ALLOC_SMALL;
case 0x09: return WOD_SAVE_XMM128_FAR;
case 0x0A: return WOD_SAVE_XMM128;
default: break;
}

uint8_t op6 = b0 & 0x3F;
if (op6 == 0x20) return WOD_PUSH2;

// 8-bit opcode (full byte match)
switch (b0)
{
case 0x00: return WOD_SET_FPREG;
case 0x01: return WOD_ALLOC_HUGE;
case 0x02: return WOD_ALLOC_LARGE;
case 0x03: return WOD_PUSH_CANONICAL_FRAME;
default:   return INVALID;
}

layout WOD (a livello di bit)

Tutte le posizioni di bit sono numerate LSB-first all'interno di ogni byte. I campi integer a più byte sono little-endian.

WOD_PUSH - 1 byte

Byte 0: [2:0] = 100b (opcode 4)
        [7:3] = Register (5 bits, AMD64 integer register number)

Effetto:PUSH <reg> regola RSP di 8 e archivia la registrazione.

WOD_PUSH2 - 2 byte

Byte 0: [5:0] = 100000b (opcode 32)
        [7:6] = Register1[1:0] (low 2 bits)
Byte 1: [2:0] = Register1[4:2] (high 3 bits)
        [7:3] = Register2 (5 bits)

Effetto:PUSH2 <reg1>, <reg2> esegue il push di due registri con una singola istruzione (APX). Regola l'RSP di 16.

WOD_PUSH_CONSECUTIVE_2 - 1 byte

Byte 0: [2:0] = 111b (opcode 7)
        [7:3] = Register (5 bits)

Effetto: Spinge Register e Register+1 consecutivamente. Regola RSP di 16 in totale. Register il valore deve essere limitato a [0, 30], in quanto il valore di 31 verrebbe posizionato Register+1 fuori dai limiti.

WOD_ALLOC_SMALL - 1 byte

Byte 0: [3:0] = 1000b (opcode 8)
        [7:4] = Size (4 bits)

Allocazione effettiva:(Size + 1) * 8 byte. Intervallo: 8–128 byte con incrementi di 8.

WOD_ALLOC_LARGE - 3 byte

Byte 0: [7:0] = 0x02 (opcode 2)
Bytes 1–2: Size (16-bit unsigned, little-endian)

Allocazione effettiva:Size * 8 byte. Intervallo: fino a 524.280 byte.

WOD_ALLOC_HUGE - 5 byte

Byte 0: [7:0] = 0x01 (opcode 1)
Bytes 1–4: Size (32-bit unsigned, little-endian)

Allocazione effettiva: Numero di byte non elaborato (nessuna scalabilità). Intervallo: fino a 4 GiB.

WOD_SET_FPREG - 2 byte

Byte 0: [7:0] = 0x00 (opcode 0)
Byte 1: [3:0] = Register (4 bits, 0–15)
        [7:4] = Offset (4 bits)

Effetto: Stabilisce un puntatore al frame. <reg> = RSP + Offset * 16.

WOD_SAVE_NONVOL - 3 byte

Byte 0: [2:0] = 110b (opcode 6)
        [7:3] = Register (5 bits)
Bytes 1–2: Displacement (16-bit unsigned, little-endian)

Effetto:MOV [RSP + Displacement * 8], <reg> salva un registro intero non volatile nello stack.

WOD_SAVE_NONVOL_FAR - 5 byte

Byte 0: [2:0] = 101b (opcode 5)
        [7:3] = Register (5 bits)
Bytes 1–4: Displacement (32-bit unsigned, little-endian)

Effetto: Uguale a WOD_SAVE_NONVOL ma con uno spostamento di byte non ridimensionato a 32 bit. Usato quando l'offset non rientra in 16 bit moltiplicati per 8.

WOD_SAVE_XMM128 - 3 byte

Byte 0: [3:0] = 1010b (opcode 10)
        [7:4] = Register (4 bits, XMM0–XMM15)
Bytes 1–2: Displacement (16-bit unsigned, little-endian)

Effetto:MOVAPS [RSP + Displacement * 16], <xmm> salva un registro XMM a 128 bit.

WOD_SAVE_XMM128_FAR - 5 byte

Byte 0: [3:0] = 1001b (opcode 9)
        [7:4] = Register (4 bits, XMM0–XMM15)
Bytes 1–4: Displacement (32-bit unsigned, little-endian)

Effetto: Uguale a WOD_SAVE_XMM128 ma con uno spostamento di byte non ridimensionato a 32 bit.

WOD_PUSH_CANONICAL_FRAME - 2 byte

Byte 0: [7:0] = 0x03 (opcode 3)
Byte 1: [7:0] = Type (8 bits)

Effetto: Indica che l'hardware/sistema operativo ha eseguito il push di un frame canonico nello stack. I valori di tipo distinguono:

• Telaio della macchina senza codice di errore
• Telaio della macchina con codice di errore
• Telaio della macchina con spinta della pila ombra
• Record di contesto

I valori di tipo esatti sono definiti dal sistema operativo. Consultare le intestazioni Windows SDK.

Riepilogo delle costanti del codice operativo

#define WOD_OP_SET_FPREG              0   // 8-bit opcode, 2 bytes
#define WOD_OP_ALLOC_HUGE             1   // 8-bit opcode, 5 bytes
#define WOD_OP_ALLOC_LARGE            2   // 8-bit opcode, 3 bytes
#define WOD_OP_PUSH_CANONICAL_FRAME   3   // 8-bit opcode, 2 bytes
#define WOD_OP_PUSH                   4   // 3-bit opcode, 1 byte
#define WOD_OP_SAVE_NONVOL_FAR        5   // 3-bit opcode, 5 bytes
#define WOD_OP_SAVE_NONVOL            6   // 3-bit opcode, 3 bytes
#define WOD_OP_PUSH_CONSECUTIVE_2     7   // 3-bit opcode, 1 byte
#define WOD_OP_ALLOC_SMALL            8   // 4-bit opcode, 1 byte
#define WOD_OP_SAVE_XMM128_FAR        9   // 4-bit opcode, 5 bytes
#define WOD_OP_SAVE_XMM128           10   // 4-bit opcode, 3 bytes
#define WOD_OP_PUSH2                 32   // 6-bit opcode, 2 bytes

Codifica del registro

I registri interi usano la numerazione AMD64 standard (5 bit, 0-31):

I campi del registro XMM sono di 4 bit (0–15) e corrispondono direttamente a XMM0–XMM15.