Ну, dwarf2 создает таблицы для каждой функции, которые содержат данные о том, что представляют собой сохраненные регистры вызываемого абонента и где в стеке они сохранены, где находится указатель / адрес возврата фрейма в стеке вызовов и некоторые другие вещи. Если вы используете dwarf2, компилятор может использовать эту информацию и эффективно восстанавливать регистры и возвращаться к вызывающим в случае исключения. Бэкэнды должны предоставлять информацию в коде, генерирующем пролог своих реализаций, сообщать GCC, какие регистры сохраняются вызываемым пользователем, и когда был сохранен указатель кадра и тому подобное.
Использование setjmp / longjmp - это просто взлом. Поскольку setjmp / longjmp не знает о структуре функции throw, он восстановит все регистры, сохраненные в буферном прыжке с помощью setjmp, даже если они не были переопределены функцией throwing. Я на самом деле не эксперт в этом, но я думаю, очевидно, что это не будет эффективным. Кроме того, каждый раз, когда вы запускаете блок try, нужно вызывать setjmp для настройки буфера, содержащего сохраненные регистры, а при использовании dwarf2 компилятор уже предоставляет всю необходимую информацию во время компиляции.
Если бэкэнды не предоставляют необходимую информацию, GCC автоматически переключится на обработку исключений на основе setjmp / longjmp.
Обратите внимание, я не эксперт GCC. Я просто перенес набор инструментов на простой процессор моего профессора, включая GCC. Я надеюсь, что смогу вам немного помочь.