LINUX.ORG.RU

gdbserver: удалённая отладка без заливки файла

 ,


0

3

Как можно организовать удалённую отладку без постоянного копирования файлика на удалённую машину, т.е. без remote put local-file remote-file? Со стороны target запускаю

gdbserver --multi :2000
, со стороны host
(gdb) target extended-remote <ip>:2000
(gdb) file ./path/to/debug/build
remote put это во-первых долго, во-вторых, на удалённой машине же в принципе может быть некуда его заливать. Нельзя ли как-нибудь файл с локальной машины смапить в озу удалённой? Архитектура одинаковая, ОС одинаковая.

★★★★★

Ответ на: комментарий от pon4ik

Актуальную, которую на хосте собрал только что. Простите, если непонятно объясняю. Я просто совершенно точно помню, как ковырялся со слитым SDK на Sony PSP, там на сонечке запускатся тоже какой-то типа gdb-выкидыш, и всё дебажилось с хоста через этот выкидыш, без копирования исполняемого файла на SD-карточку MemStick или внутренную NOR/NAND память. Правда теперь уже и не вспомнить, через что оно было сделано, и SDK тот не сыскать.

d_a ★★★★★
() автор топика
Последнее исправление: d_a (всего исправлений: 1)
Ответ на: комментарий от d_a

Просто, теоретически конечно можно как то приделать соответствующий слот в загрузчике, что бы он загружал образ из сети, но выигрыша оно почти не даст если сеть сопоставима по скорости с диском.

Не слышал я про такие возможности ни под онтопиком ни где то ещё, посмотрим чего народ скажет.

Могу посоветовать - не влинковывать debug info в бинарник а хранить в отдельном файле, тогда, возможно и заливать будет не так больно и проблема рассосётся сама собой?

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Просто, теоретически конечно можно как то приделать соответствующий слот в загрузчике, что бы он загружал образ из сети, но выигрыша оно почти не даст если сеть сопоставима по скорости с диском.

Да оно не для выигрыша, а для удобства же.

Могу посоветовать - не влинковывать debug info в бинарник а хранить в отдельном файле, тогда, возможно и заливать будет не так больно и проблема рассосётся сама собой?

Заливать-то не больно :3 У меня же просто два компьютера, к одному привинчен 485, вот я и решил так попробовать потыркаться. Интересно в принципе, как люди делают, если на таргете только тормозная флешка. Не будешь же перешивать полностью в неё файлик по 5-10 минут, просто чтобы перезапустить отладчик?! Она (флешка) же помрёт ещё до окончания процесса разработки.

d_a ★★★★★
() автор топика
Последнее исправление: d_a (всего исправлений: 1)
Ответ на: комментарий от d_a

насколько я помню, gdbserver из коробки такое не умеет.

Для embedded такое встречается. Путь решения - дописывать gdbserver под свои нужды, но проще сделать скрипт для gdb который будет автоматом писать новый бинарь.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Да, если не выпендриваться, то это просто в локальный .gdbinit

target extended-remote 192.168.0.14:2000
remote put ./build/debug/podelka podelka
и оно само заливает.

d_a ★★★★★
() автор топика
Ответ на: комментарий от Dark_SavanT

Для embedded такое встречается. Путь решения - дописывать gdbserver под свои нужды

Т.е. каждый дописывает сам, и никто ещё не опубликовал?

gdbserver тупо сохраняет файл и отдаёт заказ на исполнение через exec? Тогда нужно было бы разместить файлик на мини fuse ФС. Или через какую-нибудь обёртку перехватывать read на этот файлик и слать их по сети, а оттуда принимать байтики и отдавать загрузчику, как будто файл лежит локально. Что наводит на мысль, что можно ещё проще: примонтировать ФС, где происходит сборка, на целевой системе по NFS и не мучиться.

gag ★★★★★
()
Ответ на: комментарий от gag

Ну вот соничкин gdbserver на psp, значит, что-то такое и делал. Там ещё помню, была отдельно фича, можно было ресурсы с компа маунтить, которые игре нужны, чтобы не перекачивать туда сюда, скорей всего да, на FUSE всё и было.

d_a ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.