Почему все регистры сохраняются во время обработки исключений .NET?

Question

По крайней мере, в соответствии с описанием Mono's exception handling implementation все регистры x86 сохраняются при вызове исключения. Помимо указателя стека (ESP), указателей кадров (EBP), указателей инструкций (EIP) и регистра, который содержит объект исключения, почему другие регистры также сохранены? Зачем сохранять весь контекст, когда в .NET нет механизма для продолжения выполнения в точке сразу после броска?

UPDATE:

EMCA заявляет следующее в разделе 12.3.2.4 Обзор обработки исключений:

• Объект исключения, описывающее исключение автоматически создается CLI и надевается на в стек оценки как первый элемент при входе в предложение фильтра или catch.

• Выполнение не может быть возобновлено в месте исключения, за исключением обработчика фильтра.

Я не знаю, как «исключить с помощью обработчика фильтра» можно выполнить в свете предыдущего утверждения. Кроме того, описание кода операции endfilter имеет только два результата: «продолжить поиск другого обработчика исключений» или выполнить обработчик (который будет выполнять другой блок кодов операций CIL.) Отсутствует опция «возобновить». Поэтому я интерпретирую это несоответствие в спецификации, в основном, означает, что .NET не поддерживает продолжение выполнения в точке сразу после броска. Возможно, это было рассмотрено в какой-то момент, но никогда не было полностью реализовано и реализовано.

UPDATE 2:

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

Answer 1

Вы изучаете детали реализации: они обычно не соответствуют друг другу спецификации ECMA по многим возможным причинам (например, простота реализации, совместное использование кода, предоставление дополнительной семантики, прогнозирование будущих версий, оптимизация и т. Д.). ,

В данном конкретном случае имеется несколько соображений.

Mono выполняет обработку исключений на основе состояния процессора MonoContext: поскольку эта структура используется и в других местах, она содержит все соответствующие регистры, даже если некоторые из них могут не понадобиться в некоторых конкретных случаях. В частности, обработка исключений может быть инициирована также из исключения процессора, где все регистры должны быть восстановлены, поэтому все они собираются.

Кто-то уже заметил, что контекст используется также для отладчика.

Рассмотрите также случай с методом try/catch с уловом, являющимся простой локальной установкой var. Теперь расширенный распределитель регистров может поместить локальный var, который используется как перед броском (обратите внимание, что бросок может быть неявным, как нулевая ссылка, так обрабатывается путем исключения cpu) и после catch в регистре, например edx. Если вы не сохраните все регистры в точке броска/исключения, вы повредили состояние программы, так как edx будет перезаписан во время обработки исключений.

В качестве последнего комментария: вы обеспокоены тем, что сохранение нескольких дополнительных регистров - это трата циклов процессора? Если вы на самом деле считаете потраченные циклы, они полностью в шуме принимают все, что должно произойти во время обработки исключений.