#assembly #stack #gdb #callstack #backtrace
#сборка #стек #gdb #callstack #обратная трассировка
Вопрос:
Со следующей сборкой:
mov $2, %rax
push %rcx
call func
Раздел «стек» в gdb выглядит следующим образом:
─── Stack ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
[0] from 0x0000000000400109 in func
[1] from 0x00000000004000be in _start
И не имеет значения, добавляю я или удаляю push %rcx инструкцию. Почему gdb показывает только «стек адресов функций» и не показывает никаких изменений в стеке при нажатии вручную? То есть и push %rcx и call func изменяют регистр стека rsp , но только последний фактически изменяет то, что gdb показывает в разделе «стек».
Не мог бы кто-нибудь, пожалуйста, объяснить причину этого?
Комментарии:
1. Это какая-то пользовательская модификация gdb, и она печатает стек вызовов , иначе известный как обратная трассировка. Он показывает только вызовы вложенных функций. Чтобы посмотреть на фактический стек, сделайте что-то вроде
x/8x $rsp2. @Jester: Да, но как он определяет, какие qwords в стеке из
call, а какие изpush, для написанного вручную asm без отладочной информации? Я бы предположил, что он может искать возможные обратные адреса, то есть значения, которые указывают на текстовый раздел? Или, может быть, OP не показывает нам достаточно полную картину.
Ответ №1:
Раздел «стек» в gdb выглядит следующим образом:
«Стек» здесь означает «стек вызовов», а не «память стека».