Комментарии 12
Ну, так-то можно и по ssh поотлаживаться. Конечная хотелка: с локальной стороны использовать frontend (например, qtcreator), при этом, не копировать все .so. Вроде, в теории ограничений нет: на хосте qtcreator общается с какой-нибудь заглушкой и уверен, что общается с gdb, а заглушка просто кидает [по ssh] в удалённый gdb/gdbserver. Но вот как-то не получилось.
И попутный вопрос: зачем нужен такой gdbserver? Он нацелен на ситуации, когда target мааленький и не содержит .so.debug?
И попутный вопрос: зачем нужен такой gdbserver? Он нацелен на ситуации, когда target мааленький и не содержит .so.debug?
gdbserver и так по сети работает. Преимущество использования gdbserver над gdb на устройстве как раз в том, что вы можете отлаживать в чем угодно, я, например, чаще всего использую IDA PRO.
radare2, кстати, тоже поддерживает отладку через gdb:// протокол.
Прошу прощения за свое невежество, но совершенно не понял вопросов.
«Локальная сторона» это какая?
gdbserver нужен потому, что он всегда является ответной частью для GDB, т.е. связующим звеном между GDB и железкой.
Причем, gdbserver не всегда располагается на таргете. Например, отладка микроконтроллера с помощь программатора (отладчика): GDB и gdbserver лежат на хосте; gdbserver с одной стороны общается с GDB, с другой с программатором.
Таким образом, GDB всегда имеет один и тот же «внешний интерфейс».
«Локальная сторона» это какая?
gdbserver нужен потому, что он всегда является ответной частью для GDB, т.е. связующим звеном между GDB и железкой.
Причем, gdbserver не всегда располагается на таргете. Например, отладка микроконтроллера с помощь программатора (отладчика): GDB и gdbserver лежат на хосте; gdbserver с одной стороны общается с GDB, с другой с программатором.
Таким образом, GDB всегда имеет один и тот же «внешний интерфейс».
Можно еще про связку gdb + openocd для более низкоуровневой отладки микроконтроллеров написать.
Да там мало что отличается. Да и статей куча в интернете, что на английском, что на русском языках.
Статей куча, но раз автор решил написать про gdb — то имеет смысл и упомянуть про эту связку. Также имеет смысл упомянуть такие вещи как voltron, peda и mona.py. Хоть они и ориентированы на реверс-инжиниринг и подготовку эксплойтов, кое-какие вещи там удобны и для простой отладки с исходными кодами.
Это если автор сталкивался с этим. А писать про то, с чем не сталкивался или не работал… неправильно это. Я с OpenOCD работаю, т.к. embedded, когда начинал, показалось, что документации достаточно, даже не представляю чего бы там такое написать. Про OpenOCD недавно заметку сделал, как там быть когда нужны треды в RTOS ThreadX, но это уже конкретно OpenOCD и его исходники. Вот этой информации я в интернете не нашёл. А переливать из пустого в порожнее, «лишь бы было на хабре», ИМХО, не совсем верный путь. Дополнить ссылками статью, по советам в комментариях — эт можно.
gdb конечно хорошо, но только cout, только хардкор!
Т.к. файл configure ругается на попытку указать в качестве --prefix путь, начинающийся с ~. Поэтому, тут потребуется имя своего пользователя вписать.
воспользуйся такой конструкцией: --prefix=$HOME/gdb/builds/v2r/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Удаленная отладка в Linux при помощи связки GDB-gdbserver