> Адрес возврата это адрес возврата - его рисуют на картинках в книжках для пущего понимания и целостности картины. Эти данные не относятся к исключениям.Что значит не относятся, если адреса возврата используются при размотке стека? То есть, возможны варианты организации размотки стека, когда ради неё создаётся отдельный стек, но... Не знаю как там в C++, думаю нет, и совершенно определённо этого не делается в rust'е. В стековом фрейме всё фигня, а адресами возврата устанавливается связь между вложенными контекстами выполнения. Ради этих адресов возврата стек и существует, всё остальное в стеке оказывается там по принципу: если уж у нас есть стек, то почему бы не использовать его под локальные переменные и под передачу аргументов в функции.
Весь мой опыт отладки говорит, что адрес возврата -- это самая удобная точка отсчёта границ между стековыми фреймами. Даже если под адресом возврата лежат аргументы функции, всё равно удобнее ориентироваться на адрес возврата, потому что он будет даже тогда, когда аргументы передаются в регистрах, или когда их переменное число. Более того, если ты хочешь сделать что-нибудь типа tail-call'а, или вернуться из функции при помощи iret, хотя вызывали твою функцию командой call, или ещё какой-нибудь такой трюк провернуть, то тебе будет глубоко наплевать где там на стеке лежит значение bp/ebp/rbp, тебя будет в первую очередь интересовать, где лежит адрес возврата.
> Организация кадра выполняется модификацией регистра процессора "указатель стека" (иногда используется регистр "базы стека"). Действительно, упомянутый регистр - известное место.
Спасибо за справку.
> Тут надо понимать, что дебажная инфа не относится к исключениям.
Относится... Не относится... Какая разница мне, если при отсутствии отладочной информации я не могу увидеть осмысленного бектрейса от вылетевшего исключения? А речь идёт ведь именно о бектрейсе вполне конкретного исключения (то есть паники) на вполне конкретном коде.
Из наблюдений за тобой, я сформировал полезный совет тебе. Ну, познание -- моя больная тема: то как человеческие мозги упорядочивают входящий поток информации, которую они получают от рецепторов -- это очень интересный вопрос. И глядя на тебя, я вижу что ты немного не так расставляешь акценты, занимаясь познанием реальности. Собственно следующая портянка как раз об этом. Если тебе это tl;dr, ты можешь скипнуть к следующей цитате себя и читать оттуда.
Не надо так упорно пытаться делить вещи на те, которые относятся к X и те которые не относятся к X, для любого X. Вселенная не работает так. То что ты пытаешься делать -- это очень удобный способ упорядочивать информацию о Вселенной в голове, но надо быть готовым к тому, что отношение между вещами и X окажется субъективным. То есть с одной стороны его нет, с другой стороны оно есть -- как посмотреть. Граница между X и не-X -- это всегда размытая граница, там всегда есть серая область, которая иногда относится к X, а иногда нет.
Скажем, все твои рассуждения о стековых фреймах, построены на каком-то определении стекового фрейма, в котором очевидно упоминался rbp. Из чего по логике вытекает, что если не используется rbp или его аналог, то стекового фрейма нет. Чёткая граница между X и не-X, где X -- множество стековых фреймов. Но если ты попытаешься, например, отревёрсить программу, которая не использует rbp, ты будешь ковырять эту программу в дизассемблере и отладчике, и ты всё равно будешь думать о стековых фреймах, даже несмотря на то, что доступ к переменным на стеке программа выполняет посредством адресации относительно rsp. И тебе будет совершенно не важно, что там вумные люди пишут во всяких вумных учебниках о том, что они считают стековым фреймом. Даже более того, в качестве исторической справки, я скажу тебе, что использование bp, ebp и rbp для организации стека, возникло исходно лишь потому, что в 16-битном режиме интеловские процессоры не умеют в косвенную адресацию через sp, там все эти SIB да MOD/rm байты в системе команд кодируются так, что через sp никак. В 32-битном коде SIB и modrm декодируются несколько иначе, и они позволяют использовать esp, но... но люди продолжали использовать bp по двум причинам: во-первых, привычка, во-вторых, без фиксированной ссылки на стековый фрейм в ebp было невозможно пользоваться дебуггером высокоуровневого языка. Надо либо кодировать на каждую строчку кода смещение esp от адреса возврата на момент выполнения этой строчки кода (компилятор так или иначе отслеживает эту инфу, он её использует, но не сохраняет в бинаре), либо учить дебуггер всяким хитрым трюкам, чтобы тот анализируя выполняемые команды сам бы высчитывал все эти смещения. То есть, когда код стал 32-битным (и тем более 64-битным), использование ebp/rbp для организации стекового фрейма стало лишь данью тупости отладчиков, такой же данью тупости отладчиков, как и отладочная инфа. Ещё его можно использовать для размотки стека в случае исключений, но можно и не использовать, придумав какой-нибудь иной способ. А, если мы, разматывая стек, хотим ещё и ресурсы подбирать и освобождать, то что-то иное всё равно приходится придумывать, и это что-то иное может не включать в себя использование rbp для организации стекового фрейма. Но так или иначе, ты видишь, да? Граница между X и не-X размазалась, и уже неясно, нужен ли rbp для организации стекового фрейма, или это просто дань традиции, возникшей из-за убогости первых x86.
То же самое происходит и с отладочной информацией. Она нужна для отладки. Точка. Чёткая граница между X и не-X, где X -- это инфа для отладки. Но... эмм... если мы всунем обрезанный вариант этой отладочной инфы в релиз, то мы сможем получать осмысленные бектрейсы, которые могут помочь нам общаться с пользователями о багах. Обрезанный вариант -- это без номеров строк, без информации о размещении переменных на стеке, без всего, лишь информацию о границах функций в секции кода, и каноничные имена этих функций, со ссылками на файлы где они объявлены. То есть, это тоже, как бы, "для отладки", но в то же время, как бы, и не совсем для отладки.
Отладочная информация может использоваться и для того, чтобы определить факт того, что исключение возникло не в функции foo, а в функции bar, которая была заинлайнена в foo. Я не знаю, используется ли она в действительности всякими разными библиотеками, которые позволяют программе построить свой бектрейс. То есть, де факто, отладочная информация используется ими -- иначе бы бектрейсы программы с отладочной инфой не отличались бы от бектрейсов программ без неё. Но тут вопрос в том, может ли построитель бектрейса в C++ использовать эту информацию для определения того, что на стековом фрейме foo сверху есть ещё стековый фрейм функции bar, несмотря на то, что bar не вызывался через call, и адрес возврата не клался на стек, и вообще после того как bar был заинлайнен, при взгляде на дизассемблерный дамп даже возникает сомнение в осмысленности разговора о том, что какой-то кусок foo -- это на самом деле самостоятельная функция bar.
Более того, имея опыт создания странных вещей странными способами, я допускаю, что отладочную инфу можно использовать для организации размотки стека по исключению и для организации RAII. Не думаю, что кто-нибудь так поступает -- во всяком случае не в C++, где исключения -- это заурядный механизм, тормознутость которого и без того причиняет анальные боли, и вот только ещё не хватало парсить текстовую дебаг-инфу, и извлекать из неё информацию о переменных, чьи деструкторы надо вызвать.
Отладочная инфа или не *отладочная* инфа -- вот в чём вопрос, границы опять расплываются. Относится "отладочная" инфа к размотке стека или не относится? Не надо излишне парится о чёткости этих границ, чёткость должна быть на экзамене, потому что экзамены часто принимаются тупыми педантами. Чёткость может оказаться полезной при общении с другим человеком, но тут палка о двух концах: если твои чёткие границы между понятиями будут пролегать немного не там, где его чёткие границы между понятиями, то вам будет очень сложно понять друг-друга, более того вы будете рисковать не понять того, что вы не понимаете друг-друга, а это худшее, что может случиться в коммуникации. Даже мордобой, как способ вести коммуникацию, не столь плох, потому что он по-крайней мере несёт в себе чёткое взаимопонимание хотя бы по одному вопросу.
> Уверен, сможешь. Возможно, не с первой попытки, но сможешь. Ты специалист весьма грамотный и упорный, другое дело, что больше интересуешься высоким уровнем, а не всякими rop-гаджетами.
Это "да" или "нет"? Я знаю, что я смогу, мне в жизни удавалось заставлять работать очень странные вещи и очень странными способами. Но это не ответ на поставленный вопрос.
Впрочем, я уже догадался, что ответ -- нет. Если бы ответ был "да", ты бы не извивался тут ужом на сковородке, пытаясь изобразить что-то похожее на ответ так, чтобы оно не содержало бы в себе актуального ответа.
> Ты же сам сообщил, что из-за инлайна не будет стекового фрейма и потому в итоге вываливается паника, а иначе сделать нельзя.
Я такого не сообщал, ты не тем местом читал. У меня там выше целый пост, который приводит возможную причину паники, и не слова не сказано о том, что паника вылетела из-за отсутствия стекового фрейма. Слова о стековых фреймах были для того, чтобы обосновать поиск причины паники не только в той функции, из которой эта паника вылетела, согласно бектрейсу, но и в функциях, которые вызываются из неё, несмотря на то, что эти функции не упоминаются в бектрейсе, из чего, *как бы*, следует, что исключение возникло не в них.
Вариант для распечатки
