#gdb #linux-kernel
#gdb #linux-ядро
Вопрос:
Я использую gdb для подключения к ядру Linux 2.6.31.13, исправленному с помощью KGDB по Ethernet, и когда я пытаюсь отсоединить отладчик, я получаю это:
(gdb) quit
A debugging session is active.
Inferior 1 [Remote target] will be killed.
Quit anyway? (y or n) y
Bogus trace status reply from target: E22
после этого сеанс все еще открыт, я могу продолжать и продолжать с помощью ctrl d, и отладчик не завершается.
Я искал это сообщение в Google, и там всего 5 результатов (и ни один из них не полезен :-/ ).
Есть идеи, что это может быть и как это исправить?
Ответ №1:
Если вы очистили все точки останова на цели и «C» продолжался с последней точки останова (при условии, что целевой код не аварийно завершал работу и т.д.), Я думаю, вы будете в безопасности: при запуске kgdb все равно не будет взаимодействовать с вашей gdb, поскольку, насколько я помню, он обрабатывает ссылку только при остановке (в точке останова или исключении) в ожидании команд. Несколько быстрых нажатий Ctrl-C, если необходимо вернуть управление в gdb, затем «q», и все.
По крайней мере, таков мой опыт при отладке ko’s…
Я подозреваю, что gdb говорит это, потому что не понимает, что обращается к kgdb, а не к удаленному серверу gdb. Я не представляю, чтобы kgdb согласилась прервать поток ядра, потому что отладчик все равно был завершен!
Хммм, запоздалая мысль: Вы говорите о kgdb ‘lite’, которая теперь является частью дерева ядра, не так ли? Потому что это единственное, с чем у меня есть опыт…
PS 3 июня:
Я никогда не видел точного сообщения, о котором вы упомянули, пока не перешел на ядро 2.6.32 (в рамках миграции моих машин для разработчиков и целевых компьютеров на Lucid). И затем, к удивлению, я тоже столкнулся с этим. Здесь это, похоже, происходит в безнадежных ситуациях (например, segfault или kgbd, которые, по-видимому, сбегают после пропуска точки останова или одного шага). Единственное лекарство, которое я нашел до сих пор, заключалось в том, чтобы удалить ddd (gdb) на компьютере разработчика и перезагрузить цель. Но хорошей новостью является то, что kgdb в 2.6.32 кажется гораздо более стабильной, чем в Karmic (2.6.31).
Комментарии:
1. Я думаю, что оно должно быть полным, потому что мне пришлось залатать ядро, чтобы получить поддержку Ethernet, я думаю, у «lite» есть только последовательный порт…
2. Хммм, интересно. Я думаю, что Джейсон Вессел, разработчик kgdb, уже давно подготовил исправление для драйвера Over Ethenet, но еще не интегрировал его в дерево ядра. Ниже приведен отрывок из сообщения о kgdb-bugreport от 4 февраля 2010 года: > допустим, попробуйте kgdb через ethernet, но я видел в последних ядрах, что > патч kgdboe не существует, может кто-нибудь сказать мне, почему этот патч > удален? Или где я могу это получить? Спасибо. kgdboe никогда не был объединен с основной линией. Исправления для этого действительно существуют в git-архиве kgdb. (Ответ выше был от Джейсона, разработчика kgdb).
3. И да, обычная kgdb в настоящее время выполняет только последовательный ввод. Исправление OE для него, безусловно, существует, возможно, в репозитории sourceforge, но не существовало в дереве ядра в феврале 2010 года, т. е. в то время, когда разрабатывалась ранняя версия 2.6.4). Итак, я не знаю, есть ли у вас обычная kgdb ядра с некоторыми дополнениями, например, какой-нибудь бэкпорт, включающий драйвер, опрошенный OE, или что? И я не знаю ни из одного источника, что «старая» kgdb когда-либо обновлялась для переноса на 1.6.31, то есть на довольно недавнее ядро. Помните, откуда вы получили свой патч kgdb и / или OE?
Ответ №2:
ctrl z должно помочь вам выйти.