Sysroot linux что это
GDC/Cross Compiler/Existing Sysroot
This describes how to build or use a cross compiler if you have access to an existing system root (short sysroot). A sysroot is a folder which contains a minimal filesystem (especially libraries, the C library and header files). An example sysroot could look like this: ‘sysroot/usr’, ‘sysroot/usr/lib’, ‘sysroot/usr/include’.
Contents
The sysroot
Sysroot over SSH
If your target machine offers a fast SSH access it’s possible to use the file system of the remote machine directly. This way the crosscompiler has full access to all libraries of the remote system. If a library is missing simply install it on the remote machine using the standard package manager.
You can mount a remote sysroot by using SSHFS:
user@targethost is an SSH user / hostname account. $SYSROOT is the location where the sysroot will be mounted.
Using a compiler from gdcproject.org/downloads
You can use the compilers from http://gdcproject.org/downloads with a SSH sysroot, but the system accessed over SSH must be similar to the system the cross-compilers «emulate». For example ArchlinuxARM systems are known to work, debian systems will not work (debian uses additional patches for binutils which were not compiled into the compilers from gdcproject.org).
To use such an compiler with the SSH sysroot, use the ‘—sysroot’ switch:
Now you can link with any library installed on the remote machine:
Note: When using a Debian based sysroot system, the compiler binaries from gdcproject.org might fail to find installed libraries. Use the following options for Debian to explicitly specify the path to libraries:
You may also have to explicitly pass the ‘-ldl’ option for debian when using certain libraries.
You can also use dub to build any dub package with a cross compiler:
Building a new compiler
Specifying a target and installation folder
Replace
GNU Binutils
Note: Debian targets
If you’re target sysroot is a recent debian distribution (>= wheezy) you’ll have to apply one of the debian patches to binutils. Download it from here: http://bazaar.launchpad.net/
You then have to set DEB_TARGET_MULTIARCH before building binutils:
The correct value can be obtained by executing this on the target:
set sysroot command
Specifies the local directory that contains copies of target libraries in the corresponding subdirectories. This option is useful when debugging with gdbserver.
Syntax
Parameters
Typical use
This command is useful when debugging remote programs via gdbserver and the libraries on the target machine (running gdbserver) do not match the libraries on the source machine (running gdb). In order to set breakpoints and find source lines that correspond to different code locations GDB needs to access the library files containing symbol information. Copying those libraries to locations under a local directory and specifying its path via set sysroot allows GDB find them.
Default value
Examples
In this example we will debug a simple shared library with gdbserver:
We will use a simple program to test our library:
First, we build the application and the library and deploy it to another machine:
Second, we create a local sysroot directory that will contain copies of system libraries from the target machine:
Third, we move the libTest.so library to the directory in sysroot that corresponds to /tmp on the target machine (where we have deployed our library):
Then we run gdbserver on the deploy_machine machine:
Finally we run GDB:
Note how after we issue the set sysroot command, GDB will read all the symbols from the copied DLLs inside the /home/testuser/libtest/sysroot.
We could also have avoided copying libraries manually. If you specify remote:/ as the sysroot, GDB will download the libraries automatically:
Compatibility with VisualGDB
Cross-compilation toolchains provided with VisualGDB are configured to use correct sysroot. If you want to override this behavior you can specify the set sysroot command in the GDB Startup commands in VisualGDB Project Properties.
Как выйти на путь разработки ОС
Чтобы понять, в чем заключается роль разработчика ОС, представим, что происходит после нажатия на кнопку включения ПК.
Сначала запускается BIOS и подготавливает жизненно важное оборудование, после чего загружает в память MBR загрузочного диска, содержащую код первой части загрузчика. Под непосредственно исполняемую часть отведено всего 446 байт, чего крайне недостаточно, поэтому мало загрузчиков действительно укладываются в эти границы. В связи с этим загрузчик обычно разделяется на две части, и единственное, что делает первая часть загрузчика — читает с диска и запускает вторую часть. Вторая часть уже может занимать хоть весь диск, и обычно переводит процессор в защищенный режим, загружает в память ядро и модули, после чего передает управление ядру.
Ядро полностью подготавливает оборудование и запускает первые пользовательские процессы, обеспечивая им и их потомкам runtime-поддержку.
Таким образом, минимальное ядро должно уметь читать программы с диска, запускать их и в дальнейшем исполнять системные вызовы. Также крайне желательны вывод на монитор и механизмы защиты.
Инструментарий
Теоретически, разработку можно вести на любой ОС, но большинство инструментов рассчитаны на UNIX-подобные системы, и хотя бы собрать их на Windows уже будет страданием. Более того, поскольку WSL не поддерживает модули ядра, смонтировать образ диска не получится, и придется настраивать коммуникацию между WSL и Windows. На этом этапе уже становится проще поставить виртуальную машину с Linux. В статье будут предоставлены инструкции для Linux и macOS.
Для полного цикла разработки понадобятся редактор кода, сборочная система, отладчик с поддержкой удаленной отладки, загрузчик, виртуальная машина и, желательно, отдельная реальная машина для тестирования.
На место виртуальной машины лучше всего подходят Bochs и QEMU, поскольку они быстро запускаются и предоставляют возможность отладки запущенного ядра.
Загрузчик некоторые мазох особенно идейные разработчики пишут сами, но, если речь идет о разработке собственно операционной системы, писать загрузчик будет очень скучно, а также ненужно, поскольку есть готовые решения. Благодаря спецификации Multiboot можно написать ядро, которое будет почти из коробки загружаться с помощью, например, GRUB или LILO.
Со сборкой же всё не так просто: понадобится кросс-компилятор под x86. Зачем кросс-компилятор, если собирать под ту же архитектуру? Дело в том, что стандартный компилятор генерирует код, опирающийся на ту же ОС, на которой он запущен, или т.н. hosted-код. Hosted-код использует системные вызовы, взаимодействует с другими процессами, но привязан к операционной системе. Freestanding-код существует сам по себе и для запуска требует только само оборудование. Ядро ОС относится к freestanding, а программы, им запускаемые — к hosted. Кросс-компилятору достаточно соответствующего флага, и будет сгенерирован freestanding-код.
Подготовка
Сборка инструментов
Эту часть легче всего произвести из командной строки. Для удобства можно создать для сборки отдельный каталог, который будет легко удалить после сборки, а также задать несколько переменных окружения:
Если потом ОС понадобится собирать под другую архитектуру, достаточно будет установить другие переменные окружения, а команды скопировать.
Binutils
Загружаем и распаковываем последнюю версию с официального FTP. Осторожно: minor-версии давно перешагнули за 10, вследствие чего сортировка по алфавиту сломалась, для поиска актуальной версии можно использовать сортировку по дате последнего изменения. На момент написания статьи актуальной версией Binutils является 2.29.
Binutils не поддерживает сборку в каталоге с исходным кодом, поэтому создаем каталог рядом с распакованным кодом и заходим в него. Далее обычная сборка из исходников:
Подробнее о параметрах:
—disable-nls — то же самое, что и для Binutils;
—without-headers — не предполагать, что на целевой системе будет стандартная библиотека (этим, собственно, и отличается необходимый нам компилятор от стандартного);
—enable-languages=c,c++ — собрать компиляторы только для выбранных языков. Опционально, но существенно ускоряет сборку.
В условиях отсутствия целевой ОС обычный make && make install не подойдет, поскольку некоторые компоненты GCC ориентируются на готовую операционную систему, поэтому собираем и устанавливаем только необходимое:
libgcc — библиотека, в которой содержатся внутренние функции компилятора. Компилятор вправе вызывать их для некоторых вычислений, например, для 64-битного деления на 32-битной платформе.
На большинстве дистрибутивов Linux эту секцию можно пропустить, поскольку на них уже установлены подходящие утилиты для работы с GRUB. Для других же ОС его потребуется загрузить и собрать. Также понадобится маленькая утилита objconv:
На время сборки GRUB потребуется добавить в PATH только что собранный objconv
и кросс-инструменты (i686-elf-*).
GDB (для macOS)
Стандартная версия GDB не знает об ELF-файлах, поэтому при использовании GDB его потребуется пересобрать с их поддержкой. Загрузка, распаковка, сборка:
Образ диска
Процесс создания такового в разных ОС происходит по-своему, поэтому здесь я приведу отдельные инструкции.
Создаем пустой файл:
Создаем таблицу разделов:
Создаём файловую систему:
В дальнейшем можно будет монтировать посредством
Устанавливаем загрузчик (здесь GRUB):
Создаем пустой файл:
Разделяем таблицу разделов и единственный раздел:
Подключаем раздел как диск:
Создаем ФС, здесь FAT32:
“Склеиваем” MBR и ФС обратно:
Подключаем и запоминаем точку монтирования (обычно “/Volumes/NO NAME”):
Образ диска после этого спокойно подключается встроенными средствами системы. Можно на собственное усмотрение создать иерархию директорий и настроить загрузчик. Например, для GRUB можно создать такой grub.cfg в /boot/grub:
Настройка сборочной системы
Популярных сборочных систем в мире великое множество, поэтому инструкций к каждой здесь не будет, но общие моменты всё же опишу.
Ассемблерные файлы собираем в объектные формата ELF (32 бита):
Для компоновки используем всё тот же кросс-компилятор, но указываем чуть больше информации:
-ffreestanding — генерировать freestanding-код;
-nostdlib — не включать стандартную библиотеку, поскольку ее реализация является hosted-кодом и будет совершенно бесполезна;
-lgcc — подключаем описанную выше libgcc. Ее подключение всегда идет после остальных объектных файлов, иначе компоновщик будет жаловаться на неразрешенные ссылки;
-T — поскольку нужно где-то разместить заголовок Multiboot, обычная раскладка ELF-файла не подойдёт. Ее можно изменить при помощи скрипта компоновщика, который и задает этот флаг. Вот готовый его вариант:
Минимальное ядро
Получаем управление
Получаем управление от загрузчика в небольшом ассемблерном файле:
Proof of Work
Чтобы хоть как-то увидеть, что код действительно выполняется, можно вывести что-то на экран. Полноценный драйвер терминала — тема большая, но, вкратце, по адресу 0xB8000 располагается буфер на 2000 записей, каждая из которых состоит из атрибутов и символа. Белому тексту на черном фоне соответствует байт атрибутов 0x0F. Попробуем что-либо вывести при помощи заранее подготовленной строки:
Запуск
Копируем ядро в образ диска по нужному пути, и после этого любая виртуальная машина должна его успешно загрузить.
Отладка
Все остальное работает так же, как и всегда — точки останова, чтение памяти и пр. Также можно включить отладчик в само ядро, что позволит производить отладку на реальной машине. Можно написать его самостоятельно, но отладка ошибки в отладчике принесет много-много радости. GNU распространяет почти готовые отладчики, требующие от ядра только несколько функций. Например, для i386. Впрочем, пока это делать рано, поскольку еще нет необходимых функций, таких как установка обработчика прерывания или получения/отправки данных через последовательный порт.
Заключение
На текущий момент до минимальной рабочей операционной системы остается настроить следующее:
Кросс-компиляция в OS X под Linux используя crosstool-ng
В данном руководстве рассматривается не столько кросс-компиляция по архитектуре, сколько кросс-компиляция по системе — сборка под Linux в Darwin.
Disclaimer
В интернете есть несколько статей по сборке crosstool-ng под OS X, например на benmont.com и в официальном руководстве. Тем не менее, в некоторых статьях встречается множество ошибок и устаревших сведений, а в других описываются лишь общие черты. Здесь будет описан мой путь, по которому я успешно собрал toolchain в июле 2013.
Подготовка
Эта часть зависит от того, какой пакетный менеджер вы используете в OS X — MacPorts или Homebrew. Я для себя давно выбрал ports-way, так что буду писать исходя из этого.
1. Регистрозависимая файловая система
2. Инструменты
Предполагается, что у вас установлен MacPorts. Установим следующие пакеты:
3. Установка crosstool-ng
Собирать сам инструментарий достаточно просто, воспользуемся официальной инструкцией:
Вынужден прервать официальную инструкцию: в файле kconfig/zconf.hash.c не хватает строчки
Это потому, что ct-ng случайно хавает версию gstat из GNU-набора, вместо оригинального stat из OS X. Полюбуйтесь красотой и изящностью здешнего кода и закройте файл.
Настройка crosstool-ng
Прежде чем начать настройку, унаследуем конфигурацию от шаблона. Нас интересует x86_64-unknown-linux-gnu :
После этого вы видите меню, в котором мы будем настраивать наш инструментарий.
1. Paths and misc options
2. C compiler
3. Debug facilities
4. Companion libraries
Здесь строго следующие версии библиотек, иначе будут ошибки компиляции и autotools, эти версии подбирал методом тыка, зачастую помогал выбор более свежей.
Сборка toolchain
Практически всё готово. В процессе сборки может возникнуть следующая ошибка (версия ядра указана моя):
Ещё нужно подправить лимит открытых файлов (RE: Libc iconvdata compilation problem):
Если во время сборки у вас возникнет ошибка в gdb, если вы не отключили [*] Enable python scripting раньше:
Кажется, всё готово.
Заключение
Удаленная отладка в 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 которые будем использовать. В моем случае это:
Если все сделано правильно и прошло без ошибок, то в папке
/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) должна увидеть установку дебажной сессии:
Установка sysroot
Для корректной работы GDB, ему нужны так называемые debugging symbols, которые могут быть считаны из библиотек удаленной операционки (target). Их отсутствие является, например, причиной подобных сообщений:
А потенциально вызывать и другие неприятные проблемы отладки.
Для устранения проблемы GDB на host’е необходимо указать где взять эти самые библиотеки с помощью команды:
Если у Вас на host’е где-то завалялся образ линукса Вашго target’а, то необходимо указать путь до папки с библиотеками.
Или предварительно эти библиотеки выкачать на host:
Возвращаемся в папку с проектом, снова запускаем GDB и указываем путь до библиотек:
Теперь, периодически будут появляться сообщения типа:
Посмотреть список используемых в текущий момент библиотек можно так:
Список используемой «литературы»
/gdb/builds/v2r/termcap
7) cd
/gdb/builds/v2r/gdbserver
14) cd