Текстовые символы ядра Linux - PullRequest
0 голосов
/ 16 марта 2012

Когда я просматриваю OOPS-вывод ядра Linux, EIP и другой кодовый адрес имеют значения в диапазоне 0xC01 -----.В моих выводах System.map и objdump -S vmlinux все адреса кодов по крайней мере выше 0xC1 ------.В моем vmlinux включены символы отладки (CONFIG_DEBUG_INFO).

Когда я отлаживаю по последовательному соединению (kgdb) и загружаю gdb с gdb ./vmlinux, снова у меня возникает та же проблема, с которой я не могу совместитьУ меня в System.map и objdump вывод.Когда я запускаю where в GDB, я получаю беспорядочную путаницу в стеке:

#0 0xC01----- in ?? ()
#1 0xC01----- in ?? ()
#2 0xC01----- in ?? ()
...

Может кто-нибудь сделать какие-либо предложения о том, как решить эту / эти проблемы?Моя главная проблема заключается в том, как я на самом деле отображаю значение eip из OOPS в System.map или objdump -S vmlinux.Я знаю, что OOPS даст мне имя функции и смещение в объектном коде, но меня больше беспокоит ранее упомянутая проблема и то, почему GDB не может правильно отображать обратный след стека.

1 Ответ

0 голосов
/ 18 марта 2012

Похоже, что OOPS, потому что вы прыгнули в место, которое не является функцией.
Это легко может вызвать сбой, а также не позволит отладчику разрешить адрес в виде символа.

Вы можете проверить это, разобрав область вокруг этого EIP. Если я прав, это не имеет смысла как машинный код.

Обычно есть две причины для таких вещей:
1. Вызов функции с использованием поврежденного указателя функции. В этом случае в кадре стека перед последним должен отображаться вызывающий объект. Но у вас нет этого кадра, поэтому это может быть другая причина. 2. Переполнение стека - ваш обратный адрес поврежден, поэтому вы вернулись в неправильное местоположение. Если это так, то данные, на которые указывает ESP, должны содержать адрес в EIP. Отладка переполнения стека трудна, потому что отсутствует самый важный источник информации. Вы можете попытаться напечатать стопку в «сыром» формате (x / xa addr) и попытаться разобраться в этом.

...