Что делает RtlRestoreContext, когда ExceptionCode является STATUS_UNWIND_CONSOLIDATE?

Question

Я пытаюсь понять, как обработка исключений C++ реализована на x64 с помощью среды выполнения Visual C++.

После прочтения блога Найнив по реализации SEH на x64 на http://www.nynaeve.net/?p=110, кажется, что RtlUnwindEx называет RtlRestoreContext с ExceptionCode установлен STATUS_UNWIND_CONSOLIDATE для консолидации кадра раскручивается.

Что мне не совсем понятно, что же делает RtlRestoreContext? MSDN указывает на http://msdn.microsoft.com/en-us/site/ms680605, что «RtlRestoreContext объединяет кадры вызовов между своим фреймом и кадром, указанным в записи контекста, перед вызовом функции обратного вызова. Это скрывает кадры от любой обработки исключений, которая может возникать в функции обратного вызова».

Что означает «консолидирует кадры вызова между своим фреймом и кадром, указанным в записи контекста»? Как это «скрыть кадры от обработки исключений, которые могут возникнуть в функции обратного вызова»? Что означает «консолидация кадров» и где именно консолидируется рамка?

Скажем, обработчик уловов C++ должен быть вызван RtlRestoreContext, и он выдает другое исключение - это (re) созданное исключение, защищенное каким-то блоком SEH? ИЛИ, этот бизнес консолидации кадров каким-то образом позаботится об этом? Если да, то как?

Answer 1

См

Рисунок 6 размотки из Exception в http://www.microsoft.com/msj/0197/exception/exception.aspx

Может быть, это то, что подразумевается под «консолидацией»

Answer 2

Если следовать функциям, вы будете видеть в обстоятельствах вы ссылаются на код, код устанавливает фальшивый машинный фрейм в стеке (относительно [r8] с заполненными только RIP и RSP) из контекста , переданного в RtlRestoreContext. Затем он копирует исходный контекст в пространство стека, выделенное под рамкой машины.

Для получения дополнительной информации о раме машины см. http://msdn.microsoft.com/en-us/library/ck9asaa9.aspx (под UWOP_PUSH_MACHFRAME).

0:004> u ntdll!RtlRestoreContext+0x296 
00000000`771f0c05 83ec30   sub  esp,30h 
00000000`771f0c08 4c8bc4   mov  r8,rsp 
00000000`771f0c0b 4881ecd0040000 sub  rsp,4D0h 
00000000`771f0c12 488bf1   mov  rsi,rcx 
00000000`771f0c15 488bfc   mov  rdi,rsp 
00000000`771f0c18 b99a000000  mov  ecx,9Ah 
00000000`771f0c1d f348a5   rep movs qword ptr [rdi],qword ptr [rsi] 
00000000`771f0c20 488b842498000000 mov  rax,qword ptr [rsp+98h] 
0:004> u 
ntdll!RtlRestoreContext+0x2ba: 
00000000`771f0c28 49894018  mov  qword ptr [r8+18h],rax 
00000000`771f0c2c 488b8424f8000000 mov  rax,qword ptr [rsp+0F8h] 
00000000`771f0c34 498900   mov  qword ptr [r8],rax 
00000000`771f0c37 488bca   mov  rcx,rdx 
00000000`771f0c3a eb12   jmp  ntdll!RcFrameConsolidation (00000000`771f0c4e) 

код переходит к функции псевдо блог, о которой говорит, NTDLL! RcFrameConsolidation.

Если мы рассмотрим таблицу функций и UNWIND записи для этой функции, мы видим, что она содержит метаданные, соответствующие поддельную установку кадра стека:

0:004>.fnent ntdll!rcframeconsolidation 

...snip... 

Unwind info at 00000000`772c8e0c, 52 bytes 
    version 1, flags 0, prolog 0, codes 27 
    00: offs 0, unwind op 8, op info f UWOP_SAVE_XMM128 FrameOffset: 290 reg: xmm15. 
    02: offs 0, unwind op 8, op info e UWOP_SAVE_XMM128 FrameOffset: 280 reg: xmm14. 
    04: offs 0, unwind op 8, op info d UWOP_SAVE_XMM128 FrameOffset: 270 reg: xmm13. 
    06: offs 0, unwind op 8, op info c UWOP_SAVE_XMM128 FrameOffset: 260 reg: xmm12. 
    08: offs 0, unwind op 8, op info b UWOP_SAVE_XMM128 FrameOffset: 250 reg: xmm11. 
    0a: offs 0, unwind op 8, op info a UWOP_SAVE_XMM128 FrameOffset: 240 reg: xmm10. 
    0c: offs 0, unwind op 8, op info 9 UWOP_SAVE_XMM128 FrameOffset: 230 reg: xmm9. 
    0e: offs 0, unwind op 8, op info 8 UWOP_SAVE_XMM128 FrameOffset: 220 reg: xmm8. 
    10: offs 0, unwind op 8, op info 7 UWOP_SAVE_XMM128 FrameOffset: 210 reg: xmm7. 
    12: offs 0, unwind op 8, op info 6 UWOP_SAVE_XMM128 FrameOffset: 200 reg: xmm6. 
    14: offs 0, unwind op 4, op info f UWOP_SAVE_NONVOL FrameOffset: f0 reg: r15. 
    16: offs 0, unwind op 4, op info e UWOP_SAVE_NONVOL FrameOffset: e8 reg: r14. 
    18: offs 0, unwind op 4, op info d UWOP_SAVE_NONVOL FrameOffset: e0 reg: r13. 
    1a: offs 0, unwind op 4, op info c UWOP_SAVE_NONVOL FrameOffset: d8 reg: r12. 
    1c: offs 0, unwind op 4, op info 7 UWOP_SAVE_NONVOL FrameOffset: b0 reg: rdi. 
    1e: offs 0, unwind op 4, op info 6 UWOP_SAVE_NONVOL FrameOffset: a8 reg: rsi. 
    20: offs 0, unwind op 4, op info 5 UWOP_SAVE_NONVOL FrameOffset: a0 reg: rbp. 
    22: offs 0, unwind op 4, op info 3 UWOP_SAVE_NONVOL FrameOffset: 90 reg: rbx. 
    24: offs 0, unwind op 1, op info 0 UWOP_ALLOC_LARGE FrameOffset: 4d0. 
    26: offs 0, unwind op a, op info 0 UWOP_PUSH_MACHFRAME. 

Эффекта этого должен «трюк» VirtualUnwindEx/код обработки исключений в мышление функции, описанной в ContextRecord, является непосредственным абонентом RtlRestoreContext.

С точки зрения VirtualUnwind, callstack - это OriginalContext -> RtlRestoreContext -> [пользовательский обратный вызов], между которыми нет ничего.

Таким образом, если стек «разматывается», все промежуточные кадры между кадром, описанным в ContextRecord, и текущий контекст в RtlRestoreContext «забыты». т. е. кадры объединены в один кадр, который разматывается как одна функция. Таким образом, если в функции обратного вызова, переданной в ExceptionRecord, возникает исключение, все обработчики исключений в этих промежуточных кадрах скрыты. Как отмечает блог, эта функциональность в значительной степени полезна для обработки исключений языка.

Как указано в документации MS, локаторы промежуточных кадров стека не уничтожаются до вызова обратного вызова, что полезно, если объект исключения на некотором языке был выделен на стек стека этой функции.