Remote debugging on linux

Удаленная отладка в Linux при помощи связки GDB-gdbserver

Как всем нам известно, процесс отладки это такая вещь, важность которой трудно переоценить. Причем, понимая важность таких методов как дебажное моргание светодиодами и вывод дебажных сообщений в порт, я остаюсь при мнении, что эффективнее пошаговой отладки пока ничего не придумано. Однако, задача пошаговой отладки становится не такой тривиальной в случае программирования под Linux на встраиваемых системах (таких как rasbery pi, virt2real или промышленные процессорные модули).

Данную задачу в Linux призвана решать стандартная связка программ GDB и gdbserver. Идея в том, что пишешь на компе программу (host в терминологии GDB), компилируешь её и заливаешь на целевое устройство (target). Далее запускаешь на целевом устройстве (target) отлаживаемый файл и gdbserver, а на хосте GDB и вперед.

Схему взаимодействия такой отладки кратко можно представить так:

Исполняемый файл — это та самая программа, которую мы хотим удаленно отлаживать. Для корректной работы, экземпляр программы должен находиться не только на целевом усройстве, но и на компе (host) с которого идет отладка.
GDB — программа, которая непосредственно выполняет процесс отладки. Обычно, входит в состав тулчейна GCC и находится там же где и компилятор.
gdbserver — ответная часть GDB, которая запускает исполняемый файл в режиме отладки. Поскольку gdbserver запускается на удаленной стороне (target), то он должен быть собран под целевое устройство, при помощи кросс-компилятора. Собственно, сборке gdbserver’а из исходников и посвящена в основном данная статья.

В моём распоряжении есть плата virt2real, а так же процессорный модуль на базе процессора от TI серии AM335x. Ниже будет показана последовательность действий на примере virt2real, однако, всё тоже самое мною было успешно (и что важно — аналогично) проделано с чипом AM335x.

Примечание: операционная система, установленная на host’e — Ubuntu.12.04.

Подготовка

Создаем в своей домашней директории папку gdb, в которой и будем производить все наши манипуляции. Внутри создаем подпапку downloads:

Скачиваем необходимые нам исходники и распаковываем их. Нам понадобится сам GDB, а так же библиотека termcap (её использует GDB).

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

Собираем библиотеку termcap

Соответственно, начинаем с библиотеки termcap, потому что она потребуется позднее при сборке самого gdbserver’a. Создаем папку builds, в которую будем собирать наши программы. Внутри создаем папку v2r, в неё поместим все результаты для платформы virt2real. Ну а там уже папку termcap для построения библиотеки termcap. Переходим в созданную директорию.

Указываем системе компилятор и ranlib которые будем использовать. В моем случае это:

Теперь конфигурируем. Потребуется указать 2 параметра: —host и —prefix.

• Признаюсь, я так и не понял имеет ли значение, что указать в —host. У меня сложилось впечатление, что нет. В любом случае, я не сумел найти внятного объяснения, что именно нужно указывать в данном параметре, поэтому указал префикс компилятора. Т.е. мой компилятор называется arm-none-linux-gnueabi-gcc, поэтому в качестве —host я указал arm-none-linux-gnueabi.
• В качестве параметра —prefix указываем папку, в которую мы хотим поместить результаты работа (конфигурирования), т.е. ту папку в которой мы сейчас и находимся.

Если все сделано правильно и прошло без ошибок, то в папке

/gdb/builds/v2r/termcap будет создан Makefile.

Далее собираем библиотеку:

Собираем gdbserver

Создаем папку в которой будем собирать сервер и переходим в неё:

Указываем где взять библиотеку termcap:

Конфигурируем аналогично termcap. Тут важно отметить, что мы собираем gdbserver (а не GDB), поэтому файл configure указываем именно из папки /gdb-7.8/gdb/gdbserver:

. Поэтому, тут потребуется имя своего пользователя вписать.

Если все верно, будет создан Makefile. Далее стандартно:

Пробуем

Что бы протестировать процесс отладки создадим короткий Hello world и скомпилируем его под целевую платформу.

Исходный код файла hello.cpp:

Заливаем исполняемый файл hello и наш gdbserver на целевую плату.
Я заливаю в папку /usr/ используя SCP:

Теперь запускаем второй экземпляр терминала и подключаемся к целевой плате по ssh и переходим в папку /usr/:

Запускаем на целевой плате gdbserver, и с его помощью наш исполняемый (отлаживаемый) файл hello. Затем открываем дебажную сессию на понравившемся нам порту:

Возвращаемся на host и запускаем отлаживаемый файл hello с помощью GDB

В ответ должны увидеть приглашение от GDB:

Подключаемся к удаленному gdbserver’у используя указанный выше порт:

Получаем ответ и приглашение для ввода следующей команды:

При этом удаленная сторона (gdbserver на target в лице virt2real) должна увидеть установку дебажной сессии:

Комментарий	host	target
Ставим breakpoint на main
Идем до Breakpoint’а
Переходим к следующей строке
Переходим к следующей строке
Переходим к следующей строке
Переходим к следующей строке (которой, впрочем нет)
Запускаем программу до конца, что приводит к её завершению

На этом пример пошаговой отладки закончен. Отмечу:

• для получения полного списка команд можно воспользоваться командой help, а так же почитать книгу, посвященную отладке с помощью GDB (ссылку смотри в конце статьи)
• «ручная» отладка с помощью GDB дело весьма утомительное, так что рекомендую использовать для этих целей, например, Eclipse. К сожалению, описание подобной отладки в рамках данной статьи, увеличило бы её до неприличных размеров. В конце статьи указана ссылка на очень хорошее англоязычное описание данной темы.

Установка sysroot

Для корректной работы GDB, ему нужны так называемые debugging symbols, которые могут быть считаны из библиотек удаленной операционки (target). Их отсутствие является, например, причиной подобных сообщений:

А потенциально вызывать и другие неприятные проблемы отладки.
Для устранения проблемы GDB на host’е необходимо указать где взять эти самые библиотеки с помощью команды:

Если у Вас на host’е где-то завалялся образ линукса Вашго target’а, то необходимо указать путь до папки с библиотеками.
Или предварительно эти библиотеки выкачать на host:

Возвращаемся в папку с проектом, снова запускаем GDB и указываем путь до библиотек:

Теперь, периодически будут появляться сообщения типа:

Посмотреть список используемых в текущий момент библиотек можно так:

Список используемой «литературы»

/gdb/builds/v2r/termcap
7) cd

/gdb/builds/v2r/termcap
8) export CC=/opt/virt2real-sdk/codesourcery/arm-2013.05/bin/arm-none-linux-gnueabi-gcc
9) export RANLIB=/opt/virt2real-sdk/codesourcery/arm-2013.05/bin/arm-none-linux-gnueabi-ranlib
10) ../../../downloads/termcap-1.3.1/configure —host=arm-none-linux-gnueabi —prefix=

/gdb/builds/v2r/termcap
11) make
12) make install
13) mkdir -p

/gdb/builds/v2r/gdbserver
14) cd

/gdb/builds/v2r/gdbserver
15) export LDFLAGS=»-static -L

/gdb/builds/v2r/termcap/lib»
16) export CFLAGS=»-g -O2 -I

/gdb/builds/v2r/termcap/include»
17) ../../../downloads/gdb-7.8/gdb/gdbserver/configure —host=arm-none-linux-gnueabi —prefix=/home/den1s/gdb/builds/v2r/gdbserver —disable-werror # &&
18) make
19) make install

Источник

Debug .NET Core on Linux using SSH by attaching to a process

Starting in Visual Studio 2017, you can attach to .NET Core processes running on a local or remote Linux deployment over SSH. This article describes how to set up debugging and how to debug. For debugging scenarios using Docker containers, see Attach to a process running on a Docker container and the container tools articles instead. To debug Linux on WSL 2 from Visual Studio (no attach to process), see Debug .NET Core Apps in WSL 2 with Visual Studio.

Prerequisites

On the Visual Studio computer, you need to install either the ASP.NET and web development workload or the .NET Core cross-platform development workload.

On the Linux server, you need to install SSH server, unzip and install with either curl or wget. For example, on Ubuntu you can do that by running:

SFTP must be enabled as well as SSH. Most SSH distributions install and enable SFTP by default, but that is not always the case.

On the Linux server, install the .NET runtime on Linux, and find the page matching your Linux distribution (such as Ubuntu). The .NET SDK is not required.

Prepare your application for debugging

To prepare your application for debugging:

Consider using a Debug configuration when you build the application. It is much harder to debug retail-compiled code (a Release configuration) than debug-compiled code. If you need to use a Release configuration, first disable Just My Code. To disable this setting, choose Tools > Options > Debugging, and then deselect Enable Just My Code.

Make sure your project is configured to produce portable PDBs (which is the default setting), and make sure the PDBs are in the same location as the DLL. To configure this in Visual Studio, right-click the project, then choose Properties > Build > Advanced > Debugging Information.

Build and deploy the application

You can use several methods to deploy the app prior to debugging. For example, you can:

Copy sources to the target computer and build with dotnet build on the Linux machine.

Build the app on Windows, and then transfer the build artifacts to the Linux machine. (The build artifacts consist of the application itself, the portable PDBs, any runtime libraries it might depend on, and the .deps.json file.)

When the app is deployed, start the application.

Attach the debugger

When the application is running on the Linux machine, you are ready to attach the debugger.

In Visual Studio, choose Debug > Attach to Process….

In the Connection Type list, select SSH.

Change the Connection Target to the IP address or host name of the target computer.

If you haven’t already provided credentials, you will be prompted to enter a password and/or private key file.

There are no port requirements to configure, except the port that the SSH server is running on.

Find the process that you would like to debug.

Your code runs either in a unique process name or a process named dotnet. To find the process that you’re interested in, check the Title column, which shows the command line arguments for the process.

In the following example, you see a list of processes from a remote Linux machine over an SSH transport displayed in the Attach to Process dialog box.

Choose Attach.

In the dialog that appears, select the type of code you would like to debug. Choose Managed (.NET Core for Unix).

Use Visual Studio debugging features to debug the app.

In the following example, you see the Visual Studio debugger stopped at a breakpoint in code running on a remote Linux machine.

Источник

Отладка .NET Core в Linux с помощью SSH путем присоединения к процессу

Начиная с Visual Studio 2017 можно присоединяться к процессам .NET Core, запущенным в локальном или удаленном развертывании Linux, по протоколу SSH. В этой статье описывается настройка и выполнение процесса отладки. Сценарии отладки с использованием контейнеров Docker см. в статьях Присоединение к процессу, выполняющемуся в контейнере Docker и об инструментах для работы с контейнерами. Сведения об отладке Linux в WSL 2 из Visual Studio (без присоединения к процессу) см. в этой статье.

Предварительные требования

На компьютере Visual Studio необходимо установить рабочую нагрузку ASP.NET и разработка веб-приложений или Кроссплатформенная разработка .NET Core.

На сервере Linux необходимо установить SSH-сервер (распакуйте и установите его с помощью curl или wget). Например, в Ubuntu это можно сделать, запустив:

Протокол SFTP должен быть включен так же, как и SSH. Большинство дистрибутивов SSH устанавливают и включают SFTP по умолчанию, но это не всегда так.

На сервере Linux установите среду выполнения .NET для Linux и найдите страницу, соответствующую вашему дистрибутиву Linux (например, Ubuntu). Пакет SDK для .NET не требуется.

Подготовка приложения к отладке

Подготовка приложения для отладки

При сборке приложения рассмотрите возможность использования конфигурации «Отладка». Отладка кода, скомпилированного для розничного выпуска (конфигурация «Выпуск»), намного сложнее, чем отладка кода, скомпилированного для отладочного выпуска. Если необходимо использовать конфигурацию «Выпуск», сначала отключите режим «Только мой код». Чтобы отключить этот параметр, последовательно выберите Сервис > Параметры > Отладка, а затем снимите флажок Включить только мой код.

Убедитесь, что проект настроен на создание переносимых PDB-файлов (параметр по умолчанию) и что PDB-файлы находятся в том же расположении, что и библиотека DLL. Чтобы выполнить эту настройку в Visual Studio, щелкните проект правой кнопкой мыши, затем выберите Свойства > Сборка > Дополнительно > Отладочная информация.

Создание и развертывание приложения.

Для развертывания приложения перед отладкой можно использовать несколько методов. Например, с их помощью можно выполнять следующее.

Скопируйте источники на целевой компьютер и выполните сборку с помощью dotnet build на компьютере Linux.

Выполните сборку приложения в Windows, а затем перенесите артефакты сборки на компьютер Linux. (Артефакты сборки включают само приложение, переносимые PDB-файлы, любые библиотеки среды выполнения, от которых может зависеть приложение, и файл .deps.json.)

При развертывании приложения запустите приложение.

Подключение отладчика

После запуска приложения на компьютере с Linux можно подключить отладчик.

В Visual Studio последовательно выберите пункты Отладка > Присоединиться к процессу. .

В списке Тип подключения выберите SSH.

В поле Цель подключения укажите IP-адрес или имя узла целевого компьютера.

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

Настраивать порты не требуется, за исключением порта, на котором выполняется сервер SSH.

Найдите процесс, который нужно отладить.

Код выполняется в процессе с уникальным именем или в процессе с именем dotnet. Чтобы найти требуемый процесс, просмотрите столбец Заголовок, в котором отображаются аргументы командной строки для процесса.

В следующем примере показан список процессов на удаленном компьютере Linux, подключенных по протоколу SSH, отображаемых в диалоговом окне Присоединение к процессу.

Выберите Присоединиться.

В появившемся диалоговом окне выберите тип кода для отладки. Выберите Управляемый (.NET Core для Unix) .

Используйте функции отладки Visual Studio для отладки приложения.

В следующем примере отладчик Visual Studio остановлен в точке останова в коде, выполняющемся на удаленном компьютере Linux.

Источник