Дамп ядра DBX в sparc64 и регистры трассировки стека

Question

Предположим, у меня есть эти функции

void foo(int a, int b, int c);
void bar(int d);
void start();

И я получаю дамп ядра, который выглядит примерно так

foo(<value of a>, <value of b>, <value of c>, <three garbage values>)
bar(<value of d>, <five garbage values>)
start(<six garbage values>)
.... [other functions]

Итак, старт под названием bar, который называется foo, и мы потерпели крах в foo. Вопрос в том, отслеживают ли эти значения в стеке значения регистров%o1, .., %o5 во время вызова каждой функции или значения регистров%i0, .., %i5 в то время сбоя (имеется в виду, что если функция изменила один из этих входных регистров, значение в трассировке стека будет другим)?

Причина, по которой я спрашиваю, заключается в том, что я думал, что это значения выходных регистров, но клиент недавно обновил свое оборудование и получил дамп ядра, где один из аргументов в трассировке стека выглядит некорректно. Разборка для вызывающей стороны выглядит правильно, даже регистры, которые использовались для установки этого конкретного аргумента, и я проверил на обычное несоответствие типов, подписанный / неподписанный и т. Д.

Answer 1

Трассировки стека обычно показывают дампы стековых фреймов для каждого вызова (простите за тавтологию). За параметрами функции следуют адрес возврата, указатель на предыдущий кадр стека и т. Д. Это ваши мусорные значения. Для получения более подробной информации о расположении стека вы можете использовать Google, например, "Соглашения о вызовах AIX". Когда генерируется дамп ядра, невозможно сказать, какие значения были в стеке во время вызова функции. Вы видите значения в момент сбоя. Таким образом, если функция назначает новое значение формальному параметру или параметры были перезаписаны из-за ошибки (например, переполнения буфера в стеке), значения будут отличаться от тех, которые были на момент вызова.