Удаленная отладка процесса Linux из Windows с помощью gdb и gdbserver: что именно нужно на стороне Windows?

Question

Я использую Eclipse CDT в Windows для разработки кода на C, который собран и протестирован на удаленных системах Linux.В настоящее время код никогда не компилируется в Windows.

Я могу использовать CDT, чтобы запустить удаленный процесс на цели Linux под gdbserver, а затем подключить gdb с хоста Windows.Тем не менее, GDB немедленно завершается с ошибками, такими как:

warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB.  Attempting to continue with the default i386 settings.
[...]
Remote 'g' packet reply is too long: 74afe9bff0aee9bf02000000f4af4a00a0aee9bf[...]

Отладка между двумя системами Linux работает нормально, поэтому ясно, что я делаю что-то не так на стороне хоста Windows.Мои конкретные вопросы:

• Является ли версия gdb Cygwin достаточной для отладки удаленных процессов в Linux, или мне нужен специальный кросс-gdb для запуска его в Windows и работа с процессами Linux?Если да, можно ли где-нибудь достать такой gdb?

• Для удаленной отладки с помощью gdb необходимо, чтобы символы были доступны в хост-системе.Какой самый простой способ добиться этого?Могу ли я просто скопировать символы, созданные при сборке на цели Linux, на хост Windows, или мне нужна полная сборка для Windows?Есть ли способ избежать этого требования, чтобы я мог поставить символы только на цель?

Спасибо,

-R

---

Дополнительная информация: В FAQ по RSE есть несколько указателей, но, к сожалению, я все еще заблокирован.FAQ описывает два подхода:

• Запустить клиент gdb в удаленной системе через ssh.Проблема здесь в том, что определенные поля в модуле запуска отладки CDT привязаны к локальной системе (путь проекта, путь к исполняемому файлу и т. Д.).
• Сборка / получение кросс-отладочной версии gdb, которая поддерживает отладку процессов Linuxиз Windows.Проблема здесь в том, что мало информации о том, как этого добиться.

Я также поднял эту проблему на форуме CDT .

Answer 1

Теперь есть плагин http://marketplace.eclipse.org/content/direct-remote-c-debugging

, который позволяет удаленно запускать gdb на сервере через ssh.Он заботится о сопоставлении путей и других вещах.

Вам не нужен удаленный запуск сервера GDB

Answer 2

Просто перестройте GDB с поддержкой целевой платформы.Вы можете использовать Cygwin для этого.Пример для целевой платформы RHEL:

> wget http://ftp.gnu.org/gnu/gdb/gdb-<ver>.tar.xz
> tar -xJvf gdb-<ver>.tar.xz
> mkdir -p gdb-<ver>/build/x86_64-redhat-linux-gnu
> cd gdb-<ver>/build/x86_64-redhat-linux-gnu
> ../../configure --target=x86_64-redhat-linux-gnu
> make && make install
> x86_64-redhat-linux-gnu-gdb.exe --version

Не забудьте после этого перенастроить свою цепочку инструментов.Чтобы получить имя целевой конфигурации, вы можете использовать:

> echo ${BASH_VERSINFO[5]}

Answer 3

Visual Studio Community Edition 2017 включает в себя инструменты кросс-компиляции и отладки GDB.Соедините это с сервером Linux или подсистемой Windows Linux, и вы сможете надежно разработать код C для систем Linux.проверить это руководство.

Answer 4

Разработка программного обеспечения на Linux обычно намного проще, чем на Windows. Но это не по теме.

Что важно при отладке кросс-скомпилированных двоичных файлов, так это то, что вы используете GDB из кросс-компилятора, а не хост GDB. Например, вы не можете использовать GDB, созданный для Windows, для отладки процесса Linux (хорошо, но вы не можете). Вам необходимо использовать кросс-компилятор gdb для отладки удаленного процесса (который является частью того же набора инструментов, который использовался для сборки двоичного файла). Поскольку вы говорите, что никогда не компилируете на Windows, я уверен, что это может быть вашей проблемой. Самый простой способ заставить его работать - это просто использовать gdb из командной строки на удаленной машине, где вы компилируете, и выполнять отладку по ssh.

Answer 5

Настройка среды кросс-компиляции или кросс-отладки с помощью gcc / gdb - очень сложная проблема, и это почти никогда не самое эффективное решение.Поместить виртуальную машину Linux на ваш компьютер с Windows и отладку там будет гораздо меньше.Если вам действительно нужно отлаживать 'там', я бы предложил просто ssh-ing и использовать командную строку gdb.Если у вас нет источника, удаленная отладка с виртуальной машины Linux под вашим контролем будет практичной.