Найти информацию по адресу в отладке - PullRequest
3 голосов
/ 27 августа 2009

Я учусь исправлять некоторые ошибки времени выполнения с помощью GDB. Вот мои вопросы:

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

  2. Имея адрес, можно ли узнать, какая переменная его использует (адрес может быть в начале, конце или середине памяти переменной)?

  3. Учитывая память, используемую переменной, возможно ли найти ее ближайшие переменные внизу и прямо над ней?

Спасибо и всего наилучшего!

1 Ответ

5 голосов
/ 29 августа 2009
  1. Обычно да. Предполагая вашу программу разбился за пределами ГБД из-за SIGSEGV и оставив дамп ядра, вы можете:
    A: узнать, какие инструкция фактически вызвала нарушение доступа:

        (gdb) x/i $pc
    

    Обычно это доступ к памяти инструкция, например "movl $1,8(%eax)". Что важно тогда какое значение имеет регистр который должен указывать на действительный Память есть.
    Б. узнать значение этого регистра:

       (gdb) p/x $eax
    

    Часто это будет 0 (вы запись через указатель NULL), или какое-то бессмысленное значение, например 0x32314043 (вы испортили или перезаписать его ASCII строка).

  2. Команда GDB "info symbol" сообщит вам, какой символ (если есть) рядом с данным адресом.

  3. Используйте ту же команду "info symbol" для адресов, которые немного меньше и немного больше адреса вашей "целевой" переменной.

Обновление:
info symbol не работает с локальными (автоматическими) переменными, потому что с такими переменными не связан символ (таблица символов).

Чтобы найти информацию о локальных переменных, выполните "info locals". Затем вы можете распечатать их адреса с

(gdb) print &a_local_variable

Я не знаю никакого способа сделать обратное (то есть сопоставить адрес локальной переменной с ее символическим именем). Однако, если у вас есть небольшое количество местных жителей, обычно тривиально сопоставить адрес одному из них «от руки». А если у вас слишком много местных жителей, это плохой «запах кода» - вам, вероятно, следует реорганизовать свой код, чтобы этого не было.

...