Освобождаем консоль

Большинство Linux-приложений с графическим пользовательским интерфейсом при запуске из консоли не освобождают консоль, а запирают сесию и начинают выводить в ней свои диагностические сообщения. Нажатие Ctrl+C в этом случае приводит к остановке приложения.Сейчас я покажу как заставить свои приложения освобождать консоль.

Добавляем в функцию main() своего приложения следующий код:

      if (fork() != 0){
          exit(0);
      }
 
      close(0);
      close (1);
      close(2);
 
      int fd = open("/dev/null", O_RDWR);
      dup2(fd, 0);
      dup2(fd, 1);
      dup2(fd, 2);

Первые три строки создают новую копию процесса нашей программы и убивают родительский процесс. Затем с помощью функции close() закрываем все дескрипторы ввода-вывода, унаследованные от родительского процесса, создаем новые дескрипторы, адресованные в /dev/null, и присваиваем их своей программе.

Решение проблем, возникающих при выполнении команд ./configure, make и make install

Иногда стандартная последовательность для компиляции программы не работает. Она начинает выводить различные ошибки и не компилирует программу. Что в таком случае делать? В этой статье описано как избавиться от множества часто встречающихся ошибок.

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

Мы можем разделить ошибки на три категории:

  • Ошибки при выполнении команды ./configure
  • Ошибки при выполнении команды make
  • Ошибки при выполнении команды make install

Очевидно, что ошибки при выполнении команды ./configure, возникают во время выполнения скрипта конфигурации, ошибки при выполнении команды make возникают во время выполнения команды make, а ошибки при выполнении команды make install, соответственно, возникают при выполнении команды make install. Далее будет представлен лист типичных ошибок и способ их решения, разделенный на эти три категории.

Ошибки при выполнении команды ./configure

Следующий список содержит некоторые общие ошибки, которые может выдать каманда ./configure. Ошибки отсортированы по частоте возникновения. Сначала наиболее часто встречающиеся. Вещи между ( и ) являются опциональными, они могут не появлятся. OR, выделенное жирным курсивом означает, что несколько ошибок имеют одно решение. Текст между < и > показывает тип строки, которая должна появиться в этом месте.

1. (configure:) (error:) <somename> (&ltsomeversion> (or higher)) not found. (Please check your installation!) OR checking for <somename>… (configure:) (error:) not found. OR (configure:) (error:) <somename> (<someversion> (or newer)) is required to build <package-you’re-trying-to-compile>

  • Это обычно означает что -dev или -devel версия пакета ,который называется <somename> не установлена у вас на компьютере. Используйте менеджер пакетов вашего дистрибутива (или любой другой способ найти и установить пакет), чтобы найти пакет <somename> и установить его, если это возможно, -dev или -devel версию. Если -dev или -devel версия уже установлена, или её не сущечтвует, посмотрете на версию уже установленной. Она достаточно новая? Если она ниже, чем <someversion>, попробуйте обновить пакет. Если обновить пакет не представляется возможным, вы можете попробовать скомпилировать более мтарую версию программы. Более старые версии обычно используют более старые версии библиотек и программ, необходимых для компиляции.

2. (configure:) (error:) cannot find header (file) <somename>.h OR (configure:) (error:) (header) (file) <somename>.h missing! OR <similar>

  • Конфигурационный скрипт не может найти .h файл, необходимый для компиляции. Эта ошибка похожа на предыдущую, в которой необходимо установить -dev или -devel версию пакета. Однако, обычно не понятно какой пакет нужно установить для решения этой проблемы, так как <somename> может быть очень общим названием. Попробуйте поискать в интернетет <somename>.h, чтобы узнать в каком пакете этот файл находится, а затем установите этот пакет (и его -dev или -devel версия, если это возможно) с помощью менеджера пакетов вашего дистрибутива.

3. (configure:) (error:) no acceptable cc found in <somedirectories>

  • Вы используете для установки компилятор gcc, А переменная окружения CC отсутствует или не установлена. Убедитесь, что пакет gcc установлен, используя менеджер пакетов вашего дистрибутива. Если этот пакет не установлен, установите его. Если он установлен, попробуйте выполнить следующую команду:
[rechosen@localhost ~]$ export CC="/usr/bin/cc"

Если это помогло, вы можете добавить эту команду в /etc/profile (это файл, содержащий команды, которые выполняются когда пользователь входит в систему) и тогда вам не придется набирать её снова.

4. (configure:) (error:) C++ preprocessor «/lib/cpp» fails sanity check

  • Ваш пакет g++ отсутствует или поврежден. Используйте Используйте менеджер пакетов вашего дистрибутива (или любой другой способ найти и установить пакет), чтобы найти пакет g++ и установить его. Не забудьте, что в некоторых дистрибутивах этот пакет называется не g++. Fedora, например, использует название gcc-c++ в соем репозитарии yum. Если вы не можете найти g++, попробуйте поискать c++, cpp или gcc.

5. (configure:) (error:) C++ preprocessor «CC (-E)» fails sanity check

  • Эта ошибка вызвана странным «багом» в некоторых версиях библиотеки libtool, которая заставляет конфигурационный скрипт проверять все компиляторы поддерживающиеся libtool. Наиболее простое решение — установить g++.

Ошибки при выполнении команды make

Так как ошибки при выполнении команды make обычно очень специфичны, я дам список основных вещей, которые могут помочь:

  • Если вы компилируете программу с использованием gcc 4 (используйте gcc -dumpversion чтобы это выяснить), попробуйте использовать более старые версии компилятора. Сначала убедитесь, что у вас установлена более старая версия. Обычно это можно узнать, использовав следующую команду:
    [rechosen@localhost ~]$ ls /usr/bin/gcc*

    Если она вернет что-то вроде этого:

    /usr/bin/gcc /usr/bin/gcc32

    То можете использовать команды gcc32, чтобы скомпилировать программу в более ранними версиями gcc. Если команда не вернет подобной строки, то используя менеджер пакетов вашего дистрибутива, найдите и установите более ранние версии gcc (обычно они называются compat-gcc или gcc-<versionnumber>). После установки, вам должна быть доступна альтернативная версия gcc. Её можно найти используя команду ls. Заставить команды ./configure, make и make install использовать более старую версию gcc можно так:

    [rechosen@localhost ~]$ CC="/usr/bin/gcc32" ./configure
    [rechosen@localhost ~]$ CC="/usr/bin/gcc32" make
    [rechosen@localhost ~]$ CC="/usr/bin/gcc32" make install

    Конечно путь /usr/bin/gcc32 надо заменить на тот, по которому у вас находится альтернативная версия gcc.

  • Иногда ошибки могут вызваны простым «багом» программы. Попробуйте скачать последнюю версию программы (используя её cvs, svn или другой репозитарий, или скачав последний снимок) и скомпилируйте её, возможно эта ошибка уже исправлена.
  • Ошибка при выполнении комадны make может быть также вызвана неправильной версией необходимой библиотеки или программы. Эта проблема часто встречается для очень новых или очень старых пакетов. Проверьте зависимости пакета (они обчно написаны на сайте программы) и сравните номера версий с версиями, установленными у вас на компьютере (их обчно можно посмотреть, используя менеджер пакетов вашего дистрибутива). Если номер версии в вашей системе больше того, которые написан на сайте, возможно вы пытаетесь скомпилировать очень старый пакет. Если вам дейсвительно необходимо его скомпилировать, попробуйте установить более старые версии зависимых пакетов.Как бы то небыло, обычно лучше поискать другой способ установки этого пакета или поискать альтернативу. Если номер версии в системе меньше, чем на сайте, вы можете попробовать обновить соответствующий пакет.Вы можетепопробовать обновить требуемую библиотеку или скомпилировать более старую весию программы.Так же проверьте, может уже есть этот пакет, скомпилированный для авшего дистрибутива. Его установка, обычно, проще, чем исправление ошибок компиляции.
  • Другая вещь, которую стоит попробовать — это поиск специфической ошибки в интернете. Если вы не нашли ничего полезного, попробуйте убрать такие вещи, как номер строки (он может измениться с новой версией), номер версии (его можно заменить звездочкой, если он содержится в названии программы) и специальные символы, такие как кавычки, так как они влияют на поисковый сервис. Обычно можно найти много информации в листе рассылок. Иногда выходит патч, который исправляет ошибки в исходном коде. Его можно применить слудеющим образом:
    [rechosen@localhost ~]$ patch -Np1 <patchfile>

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

Ошибки при выполнении команды make install

Эти ошибки обычно легко понять, но я все равно про них напишу. Есть два наиболее частых случая, почему команда make install возвращает ошибку:

  • У вас нет прав пользователя root. Попробуйте выполнить команду make install, используя команду sudo, или станеть пользователем root, используя команду su. Команда sudo применяется следующим образом:
    [rechosen@localhost ~]$ sudo make install

    Она спросит пароль; обычно используется собственный пароль или пароль пользователя root. Вы можете испльзовать команду su, чтобы стать польpователем root:

    [rechosen@localhost ~]$ su

    Эта команда тоже спросит пароль, но в данном случае наобходим именно пароль пользователя root. После того, как вы стали пользователем root, просто выполните команду make install.

  • Пакет, который вы только что скомпилировали не имеет команды установки. В этом случае вам надо скопировать скомпилированный бинарный файл в директорию bin вручную. Если вы выполните команду ls в директории исходного кода, исполняемый файл должен быть светло зеленого цвета. Его надо скопировать в /usr/bin (или, если хотите, в /usr/local/bin) следующей командой:
    [rechosen@localhost ~]$ cp <executablefile> /usr/bin

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

Другие проблемы

Вот список некоторых других возможных проблем и их решения:

  • Все проходит хорошо, но когда я набираю имя программы, которую только что установил, bash говорить, что не может её найти. Это обычно происходит из-за того, что make install устанавливает все в /usr/local или in /opt/<packagename>. Посмотрите на вывод команды make install: куда скопированы файлы? Попробуйте добвавить эту директорию в переменную PATH (следующий пример приведен для пакета, установленного в /usr/local):
    [rechosen@localhost ~]$ export PATH="$PATH:/usr/local/bin"

    Вам надо заменить /usr/local/bin на директорию, в которой установлены исполняемые файлы вашего пакета. Если это помогло, добавьте эту строку в /etc/profile, чтобы вам не пришлось набирать её каждый раз. Кстати, вы можете контролировать место, куда установится пакет, указав следующую опцию, когда запускаете конфигурационный скрипт:

    [rechosen@localhost ~]$ ./configure --prefix=/usr

    Измените /usr на директорию, в которую хотите установить пакет. Не забудьте, что вы устанавливаете только префикс; бинарные файлы установятся в свою поддиректорию, библиотеки в свою, заголовочные файлы в свою и т.д. Например при использовании указанного префикса, бинарные файлы будут установлены в /usr/bin.

  • Я хочу установить очень старую версию пакета, но я не могу найти исходный код в интернете. У вас еще остается маленький шанс. Попробуйте найти rpm файл пакета той версии, которую вы хотите и скачайте соответствующий src rpm файл. Распаковать его можно следующим образом:
    [rechosen@localhost ~]$ rpm2cpio <pmfile> | cpio -idv

    Теперь можно использовать исходный код, извлеченный из rpm файла.

Введение в написание модулей ядра Linux

С давних пор, первым шагом в изучении нового языка программирования, является написание программы, которая печатает «Hello, world!». В этой статье мы используем такой подход при изучении написания простых модулей ядра Linux и драйверов устройств. Мы изучим, как напечатать «Hello, world!» из модуля ядра тремя различными способами: printk(), из /proc файла и из устройства в /dev.

Приготовления.

Модуль ядра — это часть кода ядра, которая может быть динамически загружена и выгружена во время работы ядра. Так как он запускается как часть ядра и ему необходимо близко взаимодействовать с ядром, модуль ядра не может быть скомпилирован в вакууме. Ему нужны, по крайней мере, заголовочные файлы и настройки для ядра, в которое он будет загружен. Компилирование модуля также требует набор средств разработки, такие как компилятор. Для простоты, мы сжато опишем как установить требуемые вещи для создания модуля ядра для Debian, Fedora и «ванильного» ядра Linux из тарболла. Во всех случаях, вы должны скомпилировать свой модуль относительно исходного кода работающего на вашей системе ядра.

Исходные коды ядра обычно находятся в директории /usr/src/linux, права доступа к которой имеет только root. В настоящее время, рекомендуется размещать исходные коды ядра в домашней директории, права на которую будут иметь не-root пользователи. Комманды в этой стстье запускаются не из-под root, используя sudo для временного получения привелегий root-а только тогда, когда это необходимо. Для установки sudo, прочитайте sudo(8), visudo(8) и sudoers(5). Вы можете запускать все комманды и из-под root, если пожелаете. В этом случае, вам потребуются права root-а для того, чтобы следовать инструкциям из этой статьи.

Приготовления для компилирования модулей ядра в Debian.

Пакет module-assistant для Debian настраивает систему для сборки внешних модулей ядра. Установите его с помощью:

$ sudo apt-get install module-assistant

Это все. Теперь вы можете скомпилировать модуль ядра. Дополнительно, вы можете прочитать Debian Linux Kernel Handbook, чтобы иметь более глубокое представление о работе с ядром в Debian.

Приготовления для компилирования модулей в Fedora

Пакет kernel-devel в Fedora имеет все необходимые заголовочные файлы ядра и инструменты для сборки внешних модулей ядра. Установите его с помощью:

$ sudo yum install kernel-devel

И снова, это все, что нужно, — теперь вы можете компилировать модули ядра. Документацию по теме можно найти в Fedora release notes.

«Ванильное» ядро и его настройки.

Если вы решили использовать ванильное ядро Linux, то сначала вы должны его сконфигурировать, скомпилировать, установить и перезагрузиться с вашим новым ванильным ядром. Эти действия не так уж и просты, но эта статья покрывает только базовые знания по работе с ванильным ядром.

Исходные коды стандартного ядра Linux размещаются на http://kernel.org/. Ссылка на последний стабильный релиз находится на главной странице. Скачайте полностью весь релиз, а не патч. Например, на момент написания статьи, последний стабильный релиз был расположен на http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.5.tar.bz2. Для более быстрой загрузки, найдите ближайшее к вам зеркало из списка зеркал и скачивайте с него. Используйте wget, это самый простой способ скачать исходные коды в режиме докачки. HTTP часто блокируется и если скачивание прервется, оно продолжится с того момента, на котором остановилась:

$ wget -c "http://kernel.org/pub/linux/kernel/v2.6/linux-.tar.bz2"

Распакуйте исходные коды ядра:

$ tar xjvf linux-.tar.bz2

Теперь ваше ядро расположено в linux-/. Войдите в эту директорию с начните конфигурацию:

$ cd linux-
 
$ make menuconfig

Существует набор параметров для make, чтобы автоматически собрать и установить ядро в различной форме: пакет Debian, пакет RPM, тарболл и т.д. Чтобы узнать их всех, наберите:

$ make help

Параметр, который будет работать почти на каждом дистрибутиве:

$ make tar-pkg

Когда сборка завершится, установите новое ядро с помощью:

$ sudo tar -C / -xvf linux-.tar

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

$ sudo ln -s 
 
<расположение директории с исходным кодом> 
 
/lib/modules/'uname -r'/build

Теперь искходный код ядра готов для компилирования внешних модулей. Перезагрузитесь в свое новое ядро прежде чем загружать модули, основанные на этом дереве исходных кодов.

«Hello, World!» с помощью printk()

Для нашего первого модуля, чтобы напечатать «Hello, world!», мы будем использовать модуль, который использует возможность ядра показа сообщений. В общем-то, printk() является printf() для ядра. Сообщения printk() направляются в буффер сообщений ядра и копируются /var/log/messages.

Скачайте тарболл модуля hello_prink и распакуйте его:

$ tar xzvf hello_printk.tar.gz

Он содержит два файла: Makefile, который содержит инструкции для сборки модуля, и hello_printk.c, исходный код модуля. Для начала, осмотрим Makefile:

obj-m := hello_printk.o

obj-m — это список модулей ядра для сборки. .o будет автоматически собран из соответствующего .c файла (нет необходимости указывать список исходных файлов).

KDIR  := /lib/modules/$(shell uname -r)/build

KDIR — это расположение исходного кода ядра. Текущий стандарт это ссылка на соответствующее дерево исходных кодов, содержащее скомпилированные модули.

PWD := $(shell pwd)

PWD — это текущая директория и расположения наших исходных кодов модуля.

default:
 
    $(MAKE) -C $(KDIR) M=$(PWD) modules

default это стандартный параметр make. До тех пор, пока не будет указан другой параметр, make будет исполнять правила для этого параметра. Правило, указанное здесь запускает make с рабочей директорией, содержащей исходные коды ядра и компилирует модули только в $(PWD) (локальной) директории. Это позволяет нам использовать все правила для компилирования модулей, определенные в главном дереве исходного кода ядра.

А сейчас, давайте пройдемся по коду hello_printk.c.

#include
 
#include

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

static int __init
 
hello_init(void)
 
{
 
        printk("Hello, world!\n");
 
        return 0;
 
}

Это функция инициализации модуля, которая выполняется при его первой загрузке. Ключевое слово __init указывает компилятору, что этот код будет выполнен единожды, когда модуль загрузится. Строка, содержащая printk() запишет строку «Hello, world!» в буффер сообщений ядра. Формат аргументов printk(), в большинстве случаев, идентичен формату printf(3).

module_init(hello_init);

Макрос module_init() сообщает ядру, какую функцию выполнить при загрузке модуля. Все остальное, происходящее внутри ядра — результат установок функции инициализации модуля.

static void __exit
 
hello_exit(void)
 
{
 
        printk("Goodbye, world!\n");
 
}
 
module_exit(hello_exit);

Проще говоря, функция выхода запускается один раз, когда модуль выгружается, а макрос module_exit() идентифицирует функцию выхода. Ключевое слово __exit указывает ядру, что этот код нужно выполнить единожды, во время выгрузки модуля.

MODULE_LICENSE("GPL");
 
MODULE_AUTHOR("Valerie Henson ");
 
MODULE_DESCRIPTION("\"Hello, world!\" minimal module");
 
MODULE_VERSION("printk");

MODULE_LICENSE() сообщает ядру, под какой лицензией распространяется исходный код модуля, что влияет на то, к каким символам (функциям, переменным и т.д.) он может получить доступ в главном ядре. Модуль под лицензией GPLv2 (как на примере) имеет доступ ко всем символам. Другие лицензии модуля предупредят ядро о том, что был загружен закрытый модуль, или модуль, которому нельзя доверять. Модули без MODULE_LICENSE() распознаются ядром, как модули, выпущенные не под GPLv2. Макросы MODULE_*() полезны для идентификации информации о модуле в стандартной форме.

Теперь скомпилируем и запустим код. Войдите в директорию с кодом и соберите модуль:

$ cd hello_printk
 
$ make

Затем, загрузите модуль с помощью insmod и проверьте, что он печатает свое сообщение, используя dmesg, программу, которая выводит на экран содержимое буффера сообщений ядра:

$ sudo insmod ./hello_printk.ko
 
$ dmesg | tail

Вы должны увидеть «Hello, world!». А теперь выгрузим модуль, используя rmmod, и проверим сообщение о выходе:

$ sudo rmmod hello_printk
 
$ dmesg | tail

Вы успешно скомпилировали и установили модуль ядра!

«Hello, World!» с помощью /proc

Один из простейших и наиболее популярных способов сделать связь между ядром и пользовательскими программами — файл в /proc. /proc это псевдофайловая система, где операция чтения из файлов возвращает данные, синтезированные ядром, а данные, записываемые в файлы, читаются и оперируются ядром. До появления /proc, связь пользователь-ядро осуществлялась посредством системных вызовов. Использование системных вызовов подразумевает выбор между нахождением системного вызова, который осуществляет нужное действие (зачастую это невозможно), созданием нового системного вызова (требует больших изменений в ядре, использования номера системного вызова, и в общем-то не одобряется), или использованием системного вызова ioctl(), который требует создания специального файла, с которым ioctl() оперирует (может возникнуть ошибка, и ещё больше не одобряется). /proc предоставляет простой, предопределенный путь передачи данных между ядром и пользовательским пространством с полезными инструментами и достаточной свободой действий модулей ядра.

Для наших целей, мы создадим файл в /proc, который выведет «Hello, world!» при чтении. Мы будем использовать /proc/hello_world. Скачайте и распакуйте тарболл hello_proc модуля. Заглянем в код hello_proc.c:

#include
 
#include
 
#include

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

Следующая функция вызовется, когда процесс выполнит read() на созданный нами файл в /proc. Это проще, чем реализовывать это полностью на системном вызове read(), так как нам надо разрешить считать строку «Hello, world!» только один раз.

static int
 
hello_read_proc(char *buffer, char **start, off_t offset, 
 
		int size, int *eof,
 
                void *data)
 
{

Аргументы этой функции нуждаются в подробном объяснении. buffer это указатель на буффер ядра, в который мы пишем выходные данные из read(). start используется для более сложных /proc файлов; здесь мы его игнорируем. offset указывает на то место, с которого надо начинать считывание внутри «файла»; здесь мы передадим 0 для простоты. size это размер буффера в байтах; мы должны удостовериться в том, что мы не пишем данные после того, как буффер закончится. eof указывает на конец файла. Аргумент data, опять же, для более сложных файлов и здесь игнорируется.

А теперь, тело функции:

        char *hello_str = "Hello, world!\n";
 
        int len = strlen(hello_str);
 
        if (size &lt; len)
 
                return&lt; -EINVAL;
 
        if (offset != 0)
 
                return 0;
 
        strcpy(buffer, hello_str);
 
        /*
 
         * Signal EOF.
 
         */
 
        *eof = 1;
 
        return len;
 
}

Затем, нам надо зарегистрировать подсистему /proc в функции инициализации нашего модуля:

static int __init
 
hello_init(void)
 
{
 
        if (create_proc_read_entry("hello_world", 0, 
 
				NULL, hello_read_proc,
 
                                    NULL) == 0) {
 
                printk(KERN_ERR
 
     "Unable to register \"Hello, world!\" proc file\n");
 
                return -ENOMEM;
 
        }
 
        return 0;
 
}
 
module_init(hello_init);

И отменить эту регистрацию, когда модуль выгружен (если мы этого не сделаем, то когда процесс попробует считать /proc/hello_world, файловая система /proc попробует выполнить функцию, которая больше не существует, что вызовет kernel panic).

static void __exit
 
hello_exit(void)
 
{
 
        remove_proc_entry("hello_world", NULL);
 
}
 
module_exit(hello_exit);
 
MODULE_LICENSE("GPL");
 
MODULE_AUTHOR("Valerie Henson ");
 
MODULE_DESCRIPTION("\"Hello, world!\" minimal module");
 
MODULE_VERSION("proc");

Теперь мы готовы скомпилировать и загрузить модуль:

$ cd hello_proc
 
$ make
 
$ sudo insmod ./hello_proc.ko

Появится файл под именем /proc/hello_world, который будет выводить «Hello, world!» при чтении:

$ cat /proc/hello_world
 
Hello, world!

Вы можете создать много других /proc файлов для одного и того же драйвера, добавить функции, позваляющие запись в /proc файлы, создавать директории, полные /proc файлов, и так далее. Для чего-то более сложного, чем этот драйвер, проще и безопаснее использовать вспомогательные функции seq_file при написании интерфейсных функции для /proc. Для расширения своих знаний в этой области, прочтите Driver porting: The seq_file interface.

«Hello, World!» с помощью /dev/hello_world

Теперь мы реализуем «Hello, world!» с помощью файла устройства в /dev, /dev/hello_world. Раньше файл устройства был специальным файлом, создаваемым запуском хитроумного шелл-скрипта под названием MAKEDEV, который вызывал комманду mknod для создания любого возможного файла в /dev, невзирая на то, запущено ли это устройство в системе. Потом был devfs, который создавал /dev файлы, когда к ним впервые обращались, что вызывало много интересных проблем блокировки и множество попыток открыть файл устройства, чтобы проверить его существование. Сейчас с /dev работает udev, который связывает /dev с программами пользовательского окружения. Когда модули ядра регистрируют устройсва, они появляются в файловой системе sysfs, смонтированной в /sys. Программа из пользовательского окружения, udev, следит за изменениями в /sys и динамечески создает записи в /dev, исходя из настроек, обычно размещаемых в /etc/udev.

Скачайте тарболл модуля hello_world. Рассмотрим исходный код hello_dev.c:

#include
 
#include
 
#include
 
#include
 
#include

Как мы видим из списка необходимых заголовочных файлов, для создания устройства требуется немного больше поддержки ядра, чем в предыдущих методах. fs.h включает в себя определения структур для операций над файлами, которые мы должны использовать, применительно к нашему /dev файлу. miscdevice.h включает поддержку регистрации различных файлов устройств. asm/uaccess.h влючает функции для тестирования на чтение или запись в памяти пользовательского окружения, без нарушения прав.

hello_read() — функция, вызываемая процессом системным вызовом read() к /dev/hello. Она выведет «Hello, world!» в буффер, передаваемый вызовом read().

static ssize_t hello_read(struct file * file, char * buf, 
 
                          size_t count, loff_t *ppos)
 
{
 
        char *hello_str = "Hello, world!\n";
 
        int len = strlen(hello_str); 
 
        if (count &lt; len)
 
                return -EINVAL;
 
        if (*ppos != 0)
 
                return 0;
 
        if (copy_to_user(buf, hello_str, len))
 
                return -EINVAL;
 
        *ppos = len;
 
        return len;
 
}

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

static const struct file_operations hello_fops = {
 
        .owner                = THIS_MODULE,
 
        .read                = hello_read,
 
};

Теперь создадим структуру, содержащую информацию для регистрации стороннего устройства в ядре:

static struct miscdevice hello_dev = {
 
        MISC_DYNAMIC_MINOR,
 
        /*
 
         * Name ourselves /dev/hello.
 
         */
 
        "hello",
 
        &amp;hello_fops
 
};

Как обычно, мы регистрируем устройство в функции инициализации модуля:

static int __init
 
hello_init(void)
 
{
 
        int ret;
 
        ret = misc_register(&amp;hello_dev);
 
        if (ret)
 
                printk(KERN_ERR
 
          "Unable to register \"Hello, world!\" misc device\n");
 
        return ret;
 
}
 
module_init(hello_init);

И не забываем выгружать устройство в функции выхода:

static void __exit
 
hello_exit(void)
 
{
 
        misc_deregister(&amp;hello_dev);
 
}
 
module_exit(hello_exit);
 
MODULE_LICENSE("GPL");
 
MODULE_AUTHOR("Valerie Henson ");
 
MODULE_DESCRIPTION("\"Hello, world!\" minimal module");
 
MODULE_VERSION("dev");

Скомпилируем и загрузим модуль:

$ cd hello_dev
 
$ make
 
$ sudo insmod ./hello_dev.ko

В системе появилось устройство с именем /dev/hello, которое выводит «Hello, world!» в момент считывания root-ом:

$ sudo cat /dev/hello
 
Hello, world!

Но оно не может считаться обычным пользователем:

$ cat /dev/hello
 
cat: /dev/hello: Permission denied
 
$ ls -l /dev/hello
 
crw-rw---- 1 root root 10, 61 2007-06-20 14:31 /dev/hello

Это происходит при стандартном правиле udev, которое, при появлении нового устройства, создает файл под названием /dev/<имя_устройства> и присваивает ему права на чтение 0660. Нам необходимо создать вместо устройства ссылку, читаемую обычными пользователями, с именем /dev/hello_world. Для того, чтобы это сделать, напишем правило udev.

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

KERNEL=="hello", SYMLINK+="hello_world", MODE="0444"

Разобьем это правило на части и более подробно разберем каждую из них.

KERNEL==»hello» приводит к выполнению правила, когда устройство с именем в строке (== это оператор сравнения) появляется в /sys. Устройство hello появляется когда мы вызываем misc_register() со структура, содержащей имя устройства «hello». Вот результат в /sys:

$ ls -d /sys/class/misc/hello/
 
/sys/class/misc/hello/

SYMLINK+=»hello_world» приказывает добавить hello_world к списку ссылок, которые должны создаваться при появлении устройства. В нашем случае, мы знаем, что список будет состоять из одной ссылки, но другие устройства могут иметь много udev правил, которые создают другие ссылки, так что было бы неплохо это сделать.

MODE=»0444″ назначает права доступа к оригинальному файлу устройства на 0444, что позволяет получить доступ на чтение к этому файлу.

Очень важно использовать правильный оператор (==, += или =), во избежание появления неожиданного результата.

Теперь, когда мы понимаем, что делает это правило, давайте установим его в директорию /etc/udev. Файлы правил udev раположены в той же манере, что и скрипты инициализации System V в /etc/init.d/. Udev выполняет каждый скрипт из директории правил udev, /etc/udev/rules.d, в алфавитном/номерном порядке. Также, как и скрипты инициализации System V, файлы в /etc/udev/rules.d являются обычными ссылками на реально существующие файлы, так что правила будут выполнятся в правильном порядке.

Скопируйте файл hello.rules из директории hello_dev в /etc/udev и создайте ссылку к нему, которая будет выполнятся до других файлов правил:

$ sudo cp hello.rules /etc/udev/
 
$ sudo ln -s ../hello.rules /etc/udev/rules.d/010_hello.rules

Теперь, перезагрузите драйвер hello world и посмотрите на записи в /dev:

$ sudo rmmod hello_dev
 
$ sudo insmod ./hello_dev.ko
 
$ ls -l /dev/hello*
 
cr--r--r-- 1 root root 10, 61 2007-06-19 21:21 /dev/hello
 
lrwxrwxrwx 1 root root      5 2007-06-19 21:21 /dev/hello_world -&gt; hello

Теперь у нас есть /dev/hello_world! Наконец, проверьте, что вы можете считывать устройства «Hello, world!», как обычный пользователь:

$ cat /dev/hello_world
 
Hello, world!
 
$ cat /dev/hello
 
Hello, world!

За более подробной информацией по написанию правил udev, обращайтесь к Writing udev rules, написанную Дэниэлом Дрэйком.

Изучаем параметры gcc

Перевод статьи «Getting Familiar with GCC Parameters», автор — Mulyadi Santosa

gcc (GNU C Compiler) — набор утилит для компиляции, ассемблирования и компоновки. Их целью является создание готового к запуску исполняемого файла в формате, понимаемом вашей ОС. Для Linux, этим форматом является ELF (Executable and Linking Format) на x86 (32- и 64-битных). Но знаете ли вы, что могут сделать для вас некоторые параметры gcc? Если вы ищете способы оптимизации получаемого бинарного файла, подготовки сессии отладки или просто наблюдать за действиями, предпринимаемыми gcc для превращения вашего исходного кода в исполняемый файл, то знакомство с этими параметрами обязательно. Так что, читайте.

Напомню, что gcc делает несколько шагов, а не только один. Вот небольшое объяснение их смысла:

Препроцессирование: Создание кода, более не содержащего директив. Вещи вроде «#if» не могут быть поняты компилятором, поэтому должны быть переведены в реальный код. Также на этой стадии разворачиваются макросы, делая итоговый код больше, чем оригинальный. [1]

Компиляция: Берется обработанный код, проводятся лексический и синтаксический анализы, и генерируется ассемблерный код. В течение этой фазы, gcc выдает сообщения об ошибках или предупреждениях в случае, если анализатор при парсинге вашего кода находит там какие-либо ошибки. Если запрашивается оптимизация, gcc продолжит анализировать ваш код в поисках улучшений и манипулировать с ними дальнейшем. Эта работа происходит в многопроходном стиле, что показывает то, что иногда требуется больше одного прохода по коду для оптимизации. [2]

Ассемблирование: Принимаются ассемблерные мнемоники и производятся объектные коды, содержащие коды команд. Часто недопонимают то, что на стадии компиляции не производятся коды команд, это делается на стадии ассемблирования. В результате получаются один или более объектных файла, содержащие коды команд, которые являются действительно машинозависимыми. [3]

Компоновка: Трансформирует объектные файлы в итоговые исполняемые. Одних только кодов операции недостаточно для того, чтобы операционная система распознала и выполнила их. Они должны быть встроены в более полную форму. Эта форма, известная как бинарный формат, указывает, как ОС загружает бинарный файл, компонует перемещение и делает другую необходимую работу. ELF является форматом по умолчанию для Linux на x86. [4]

Параметры gcc описаны здесь, прямо и косвенно затрагивая все четыре стадии, поэтому для ясности, эта статья построена следующим образом:

— Параметры, относящиеся к оптимизации

— Параметры, относящиеся к вызову функций

— Параметры, относящиеся к отладке

— Параметры, относящиеся к препроцессированию

Прежде всего, давайте ознакомимся с вспомогательными инструментами, которые помогут нам проникать в итоговый код:

— Коллекция утилит ELF, которая включает в себя такие программы, как objdump и readelf. Они парсят для нас информацию о ELF.

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

— time, простой способ узнать общее время работы программы.

Следующие инструкции могут быть применены в gcc версий 3.x и 4.x, так что они достаточно общие. Начнем копать?

Параметры, относящиеся к оптимизации кода

.

gcc предоставляет очень простой способ производить оптимизацию: опция -O. Она и ускоряет выполнение вашего кода, и сжимает размер итогового кода. У неё существует пять вариантов:

— от -O0 (O ноль) до -O3. «0» означает отсутствие оптимизации, а «3» — наивысший уровень оптимизации. «1» и «2» находятся между этими краями. Если просто используете -O без указания номера, это будет означать -O1.

— -Os говорит gcc оптимизировать размер. В общем-то, это похоже на -O2, но пропускает несколько шагов, которые могут увеличить размер.

Какое ускорение в действительности можно от них получить? Что ж, предположим, у нас есть такой код:

#include 
 
int main(int argc, char *argv[])
 
{
 
   int i,j,k;
 
   unsigned long acc=0; 
 
   for(i=0;i&lt;10000;i++)
 
        for(j=0;j&lt;5000;j++)
 
                for(k=0;k&lt;4;k++)
 
                        acc+=k;
 
   printf("acc = %lun",acc);
 
   return 0;
 
}

С помощью gcc, создадутся четыре разных бинарных файла, используя каждый из -O вариантов (кроме -Os). Утилита time запишет их время исполнения, таким образом:

$ time ./non-optimized
Без оптимизации -O1 -O2 -O3
real 0.728 0.1 0.1 0.1
user 0.728 0.097 0.1 0.1
sys 0.000 0.002 0.000 0.000

Для упрощения, будем использовать следующие обозначения:

Non-optimized обозначает исполняемый файл, скомпилированный с опцией -O0.

OptimizedO1 обозначает исполняемый файл, скомпилированный с опцией -O1.

OptimizedO2 обозначает исполняемый файл, скомпилированный с опцией -O2.

OptimizedO3 обозначает исполняемый файл, скомпилированный с опцией -O3.

Как вы могли заметить, время выполнения программы, скомпилированной с -O1 в семь раз меньше, чем время выполнения программы, при компиляции которой не использовалась оптимизация. Обратите внимание, что нет большой разницы между -O1, -O2 и -O3, — на самом деле, они почти одинаковы. Так в чем же магия -O1?

После беглого изучения исходного кода, вы должны отметить, что такой код конечен для оптимизации. Прежде всего, давайте посмотрим на короткое сравнение дизассемблированных версий non-optimized и optimizedO1:

$ objdump -D non-optimized
 
$ objdump -D optimizedO1

(Примечание: вы можете получить другие результаты, поэтому используйте эти как основные)

Non-optimized OptimizedO1
mov 0xfffffff4(%ebp)

add %eax,0xfffffff8(%ebp)

addl $0x1,0xfffffff4(%ebp)

cmpl $0x3,0xfffffff4(%ebp)

add $0x6,%edx

add $0x1,%eax

cmp $0x1388,%eax

Приведенные примеры реализуют самый вложенный цикл (for (k=0;k<4;k++)). Обратите внимание на различие: неоптимизированный код напрямую загружает и хранит из адреса памяти, в то время как optimized01 использует регистры ЦПУ в качестве сумматора и счетчик цикла. Как вам, возможно, известно, доступ к регистрам может быть получен в сотни или тысячи раз быстрее, чем к ячейкам ОЗУ.

Не удовлетворяясь простым использованием регистров ЦПУ, gcc использует другой трюк оптимизации. Давайте снова посмотрим дизассемблированный код optimizedO1 и обратим внимание на функцию main():

......
 
   08048390 :
 
   ...
 
   80483a1:       b9 00 00 00 00          mov    $0x0,%ecx
 
   80483a6:       eb 1f                   jmp    80483c7 
 
   80483a8:       81 c1 30 75 00 00       add    $0x7530,%ecx

0x7530 это 30000 в десятичной форме, поэтому мы можем быстро угадать цикл. Этот код представляет собой самый вложенный и самый внешний циклы (for(j=0;j<5000;j++) … for(k=0;k<4;k++)), так как они являются буквальным запросом на 30000 проходов. Примите во внимание, что вам нужно всего лишь три прохода внутри. Когда k=0, acc остается прежним, поэтому первый проход можно проигнорировать.

   80483ae:       81 f9 00 a3 e1 11       cmp    $0x11e1a300,%ecx
 
   80483b4:       74 1a                   je     80483d0 
 
   80483b6:       eb 0f                   jmp    80483c7

Хмм, теперь это соответствует 300 000 000 (10 000*5 000*6). Представлены все три цикла. После достижения этого числа проходов, мы переходим прямо к printf() для вывода суммы (адреса 0x80483d0 — 0x80483db).

   80483b8:       83 c2 06                add    $0x6,%edx
 
   80483bb:       83 c0 01                add    $0x1,%eax
 
   80483be:       3d 88 13 00 00          cmp    $0x1388,%eax
 
   80483c3:       74 e3                   je     80483a8 
 
   80483c5:       eb f1                   jmp    80483b8

Шесть добавляется в сумматор при каждой итерации. В итоге, %edx будет содержать всю сумму после выполнения всех трех циклов. Третья и четвертая строки показывают нам, что после выполнения 5000 раз, должен быть переход к адресу 0x80483a8 (как указано ранее).

Мы можем заключить, что gcc создает здесь упрощение. Вместо прохода три раза в самый вложенный цикл, он просто добавляет шесть для каждого среднего цикла. Это звучит просто, но это заставляет вашу программу сделать только 100 000 000 проходов вместо 300 000 000. Это упрощение, называемое разворачиванием цикла, одно из тех задач, которые делают -O1/2/3. Конечно же, вы и сами можете это сделать, но иногда неплохо знать, что gcc может определить такие вещи и оптимизировать их.

С опциями -O2 и -O3 gcc тоже пытается произвести оптимизацию. Обычно она достигается посредством переупорядочивания [5] и трансформацией кода. Целью этой процедуры является устранить столько ошибочных ветвей, сколько возможно, что повышает качество использования конвейера. Например, мы можем сравнить, как non-optimized и optimizedO2 выполняет самый внешний цикл.

 80483d4:       83 45 ec 01             addl   $0x1,0xffffffec(%ebp)
 
 80483d8:       81 7d ec 0f 27 00 00    cmpl   $0x270f,0xffffffec(%ebp)
 
 80483df:       7e c4                   jle    80483a5

Бинарный файл non-optimized использует jle для выполнения перехода. Математически это означает, что вероятность выбора ветви 50%. С другой стороны, версия optimizedO2 использует следующее:

80483b4:       81 c1 30 75 00 00       add    $0x7530,%ecx
 
80483ba:       81 f9 00 a3 e1 11       cmp    $0x11e1a300,%ecx
 
80483c0:       75 e1                   jne    80483a3

Теперь, вместо jle используется jne. При условии, что любое целое может быть сопоставлено в предыдущем cmp, нетрудно сделать вывод, что это увеличит шанс выбора ветви почти до 100%. Это небольшое, но полезное указание процессору для определения того, какой код должен быть выполнен. Хотя, для большинства современных процессоров, этот вид трансформации не является ужасно необходимым, так как предсказатель переходов достаточно умен для того, чтобы сделать это сам.

Для доказательства того, как сильно это изменение может помощь, к нам на помощь придет OProfile. Oprofile выполнен для записи числа изолированных ветвей и изолированных ошибочных ветвей. Изолированные здесь обозначает «выполненные внутри конвейера данных ЦПУ»

$ opcontrol --event=RETIRED_BRANCHES_MISPREDICTED:1000 --event=RETIRED_BRANCHES:1000;

Мы запустим non-optimized и optimizedO2 пять раз каждый. Затем мы возьмем максимум и минимум примеров. Мы посчитаем степень ошибки, используя эту формулу (выведена отсюда).

Степень ошибки = изолированные ошибочные ветви / изолированные ветви

Теперь вычислим степень ошибки для каждого бинарного файла. Для non-optimized получилось 0,5117%, в то время как optimizedO2 получил 0,4323% — в нашем случае, выгода очень мала. Фактическая выгода может различаться для реальных случаев, так как gcc сам по себе не может много сделать без внешних указаний. Пожалуйста, прочтите о __builtin_expect() в документации по gcc для подробной информации.

Параметры, относящиеся к вызову функций

По существу, gcc предоставляет вам несколько путей управления тем, как вызывается функция. Сначала давайте рассмотрим встраивание. С помощью встраивания, вы сокращаете стоимость вызова функции, так как тело функции подставлено прямо в вызывающую функцию. Пожалуйста, учтите, что это не по умолчанию, а только когда вы используете -O3 или, по крайней мере, -finline-functions.

Как полученный бинарный файл выглядит после того, как gcc сделает встраивание? Рассмотрим следующий листинг:

#include 
 
inline test(int a, int b, int c)
 
{
 
        int d;
 
        d=a*b*c;
 
        printf("%d * %d * %d is %dn",a,b,c,d);
 
}
 
static inline test2(int a, int b, int c)
 
{
 
         int d;
 
         d=a+b+c;
 
         printf("%d + %d + %d is %dn",a,b,c,d);
 
}
 
int main(int argc, char *argv[])
 
{
 
        test(1,2,3);
 
        test2(4,5,6);
 
}

Скомпилируем этот код со следующим параметром:

$ gcc -S -O3 -o

-S указывает gcc остановиться сразу после стадии компиляции (мы расскажем о ней позже в этой статье). Результат будет следующим:

....
 
test:
 
        pushl   %ebp
 
        movl    %esp, %ebp
 
        pushl   %ebx
 
....
 
main:
 
        leal    4(%esp), %ecx
 
        andl    $-16, %esp
 
        pushl   -4(%ecx)
 
...
 
        movl    $6, 16(%esp)
 
        movl    $3, 12(%esp)
 
        movl    $2, 8(%esp)
 
        movl    $1, 4(%esp)
 
        movl    $.LC0, (%esp)
 
        call    printf
 
...
 
        movl    $15, 16(%esp)
 
        movl    $6, 12(%esp)
 
        movl    $5, 8(%esp)
 
        movl    $4, 4(%esp)
 
        movl    $.LC1, (%esp)
 
        call    printf
 
...

И test(), и test() действительно встроены, но вы также можете видеть test(), который остался вне main(). Вот где играет роль ключевое слово static. Написав, что функция — static, вы сообщаете gcc, что эта функция не будет вызываться из какого-либо внешнего объектного файла, поэтому нет нужды порождать коды. Таким образом, это экономит размер, и если вы можете сделать функцию статичной, сделайте это где только возможно. С другой стороны, будьте благоразумны при решении, какая функция должна быть встраиваемой. Увеличение размера для небольшого увеличения скорости не всегда оправдано.

С помощью некоторой эвристики, gcc решает, должна быть функция встраиваемой, или нет. Одним из таких доводов является размер функции в терминах псевдо-инструкций. По умолчанию, лимитом является 600. Вы можете поменять этот лимит, используя -finline-limit. Проэксперементируйте для нахождения лучших лимитов встраивания для вашего конкретного случая. Также возможно переделать эвристику так, чтобы gcc всегда встраивал функцию. Просто объявите вашу функцию так:

__attribute__((always_inline)) static inline test(int a, int b, int c)

Теперь перейдем к передаче параметров. На архитектуре x86, параметры помещаются в стек и позже достаются из стека для дальнейшей обработки. Но gcc дает вам возможность изменить это поведение и использовать вместо этого регистры. Функции, у которых меньше трех параметров могут использовать эту возможность указанием -mregparm=, где n — число регистров, которое вы хотите использовать. Если мы применим этот параметр (n=3) к предыдущему коду, убрав атрибут inline и не используя оптимизацию, мы получим:

...
 
test:
 
        pushl   %ebp
 
        movl    %esp, %ebp
 
        subl    $56, %esp
 
        movl    %eax, -20(%ebp)
 
        movl    %edx, -24(%ebp)
 
        movl    %ecx, -28(%ebp)
 
...
 
main:
 
...
 
        movl    $3, %ecx
 
        movl    $2, %edx
 
        movl    $1, %eax
 
        call    test

Вместо стека, используются EAX, EDX и ECX для хранения первого, второго и третьего параметров. Поскольку доступ к регистру происходит быстрее, чем к ОЗУ, это будет одним из способов уменьшить время работы. Хотя вы должны обратить внимание на следующие вещи:

— Вы ДОЛЖНЫ компилировать весь ваш код с таким же числом -mregparm регистров. Иначе у вас будут проблемы с вызовом функций из другого объектного файла, если они будут принимать разные соглашения.

— Используя -mregparm, вы разрушаете совместимый с Intel x86 бинарный интерфейс приложений (ABI). Поэтому, вы должны учитывать это, если вы распространяете свое ПО только в бинарной форме.

Возможно, вы заметили эту последовательность в начале каждой функции:

push   %ebp
 
mov    %esp,%ebp
 
sub    $0x28,%esp

Эта последовательность, также известная как пролог функции, написана чтобы установить указатель фрейма (EBP). Это приносит пользу, помогая отладчику делать трассировку стека. Следующая структура поможет вам понять это [6]:

[ebp-01] Последний байт последней локальной переменной

[ebp+00] Старое значение ebp

[ebp+04] Возвращает адрес

[ebp+08] Первый аргумент

Можем мы пренебречь этим? Да, с помощью -fomit-frame-pointer, пролог будет укорочен, так что функция начнется просто с выделения стека (если есть локальные переменные):

sub    $0x28,%esp

Если функция вызывается очень часто, вырезание пролога спасет несколько тактов ЦПУ. Но будьте осторожны: делая это, вы также усложняете отладчику задачу по изучению стека. Например, давайте добавим test(7,7,7) в конец test2() и перекомпилируем с параметром -fomit-frame-pointer и без оптимизации. Теперь запустите gdb для исследования бинарного файла:

$ gdb inline
 
(gdb) break test
 
(gdb) r
 
Breakpoint 1, 0x08048384 in test ()
 
(gdb) cont
 
Breakpoint 1, 0x08048384 in test ()
 
(gdb) bt
 
#0  0x08048384 in test ()
 
#1  0x08048424 in test2 ()
 
#2  0x00000007 in ?? ()
 
#3  0x00000007 in ?? ()
 
#4  0x00000007 in ?? ()
 
#5  0x00000006 in ?? ()
 
#6  0x0000000f in ?? ()
 
#7  0x00000000 in ?? ()

При втором вызове test, программа остановилась, и gdb вывел трассировку стека. В нормальной ситуации, main() должна идти в фрейме №2, но мы видим только знаки вопроса. Запомните, что я сказал про расположение стека: отсутствие указателя фрейма мешает gdb находить расположение сохраненного возвращаемого адреса в фрейме №2.

Опции, относящиеся к отладке.

Каждый иногда нуждается в отладке его или её кода. Когда это время приходит, обычно вы запускаете gdb, ставите точки останова там и тут, анализируете бэктрейсы, и так далее, чтобы выявить расположение нарушающего работу кода. А что получаете на самом деле? Если вы не используете опции отладки, вы просто получаете адрес, указывающий на регистр EIP.

Вот в чем проблема, в действительности вы не хотите адрес. Вы хотите, чтобы gdb или другой отладчик просто показал требуемые строки. Но gdb не может этого сделать без определенного вида помощи. Эта помощь, называемая отладкой с приписываемыми форматами записи (Debugging With Attributed Record Formats — DWARF), помогает вам выполнять отладку на уровне исходного кода.

Как это сделать? Используйте -g при компиляции в объектный код, то есть:

  gcc -o -g test test.c

Что такого добавляет gcc, что отладчик может сопоставлять адрес с исходным кодом? Вам нужна dwarfdump [7] чтобы узнать это. Это утилита находится внутри тарболла libdwarf или в RPM, так что вы не найдете её в виде отдельного пакета. Скомпилируйте её сами или просто установите из репозитория вашего дистрибутива; оба варианта должны сработать. В этой части статьи я использую версию 20060614 RPM.

Используя readelf, вы можете отметить, что в неотлаженной версии первого листинга существует 28 разделов:

 $ readelf -S ./non-optimized

Но в отлаженной версий есть 36 разделов. Новые разделы:

* debug_arranges

* debug_pubnames

* debug_info

* debug_abbrev

* debug_line

* debug_frame

* debug_str

* debug_loc

Вам не нужно копаться во всех этих разделах; для быстрого изучения, будет достаточно рассмотреть .debug_line. Команда, которая вам нужна:

$ /path/to/dwarfdump -l <object width="100" height="100" type="application/x-shockwave-flash"></object>

Вот пример того, что вы получите:

 .debug_line: line number info for a single cu
 
   Source lines (from CU-DIE at .debug_info offset 11):
 
         [row,column]
    //
 
 /code/./non-optimized.c:  [  3,-1]        0x8048384       // new statement
 
 /code/./non-optimized.c:  [  5,-1]        0x8048395       // new statement
 
 ...............

Интерпретация этих сообщений довольно простая. Возьмите первую запись (идущую за строкой ) в качестве примера:

  line number 3 in file non-optimized.c is located in address 0x8048384.

gdb дает ту же информацию:

 $ gdb non-optimized-debugging
 
   (gdb) l *0x8048384
 
   0x8048384 is in main (./non-optimized.c:3).

readelf также предоставляет похожую информацию, используя —debug-info:

 $ readelf --debug-dump=line <object width="100" height="100" type="application/x-shockwave-flash"></object>

И readelf, и dwarfdump могут анализировать информацию отладки, так что вы вольны выбирать сами.

Что вы должны понимать, так это то, что исходный код сам по себе не встроен в объектный файл. На самом деле, отладчик должен проверять отдельный файл исходного кода. Запись в колонке помогает определять, откуда загружать файл исходного кода. Учтите, что она содержит полный путь, что значит невозможность его нахождения gdb в случае перемещения или переименования.

gcc сам имеет возможность давать много информации об отладке. Кроме DWARF, существуют:

* Stabs: -gstabs производит собственный формат stabs, в то время, как -gstabs+ включает в себя специфичные расширения GNU.

* Common Object File Format (COFF): Создается с помощью -gcoff.

* XCOFF: Создается с помощью -gxcoff. Если вы предпочитаете включать расширения GNU, используйте -gxcoff+.

* Virtual Memory System (VMS): Создается с помощью -gvms.

Каждый из этих форматов описаны в ссылках ([8], [9] и [10]), но для x86-совместимой архитектуры, без проблем, вам лучше использовать формат DWARF. Последней спецификацией DWARF является DWARF третьей версии, и gdb может создавать её с помощью -gdwarf-2. Это может ввести в заблуждение новых пользователей, так как вы можете подумать, что такая опция создаст информацию DWARF 2. На самом деле, DWARF 2 объединен с некоторыми возможностями DWARF 3. Не каждый отладчик поддерживает третью версию, поэтому используйте её с осторожностью.

Хотя не всегда все идет так гладко. Когда вы комбинируете опции -O и -g, для информации о строке необходимо установить связь с фактическим кодом в упомянутом сдвиге адреса. Пример может это пояснить. Возьмите файл (я снова использую первый листинг) и скомпилируйте его:

 $ gcc -O2 -ggdb -o debug-optimized listing-one.c
 
   $ readelf --debug-dump=line debug-optimized
 
   ..
 
   Special opcode 107: advance Address by 7 to 0x80483aa and Line by 4 to 11
 
   ...

Но что говорит gdb?

 $ gdb debug-optimized
 
   (gdb) l *0x80483aa
 
   0x80483aa is in main (./non-optimized.c:11).
 
   ...
 
   11              printf("acc = %lun",acc);
 
   ...
 
   (gdb) disassemble main
 
   ...
 
   0x080483aa :   add    $0x6,%edx
 
   0x080483ad :   cmp    $0x1388,%eax
 
   ...

Здесь вы видите полное расхождение. Изучая одну информацию об отладке, вы будете ожидать, что указанный адрес содержит что-то вроде инструкции CALL. Но в действительности, вы получите инструкции ADD и CMP, что больше похоже на конструкцию цикла. Это побочный эффект действий оптимизации — в этом случае меняется порядок инструкций. Так что возьмите себе за правило не смешивать опции -g (или её варианты) c -O.

Опции, управляющие стадиями компиляции.

В целях изучения, иногда вы хотите узнать, как ваш исходный код трансформируется в исполняемый. К счастью, gcc предоставляет вам опции для остановки на любой стадии обработки. Вспомните, что gcc имеет несколько стадий завершения, — например, компоновку. Есть такие опции:

* -c останавливает на стадии ассемблирования, но пропускает компоновку. Результатом является объектный код.

* -E останавливает на стадии препроцессинга. Все директивы препроцессора развернуты, так что вы видите только чистый код.

* -S останавливает после компиляции. Она оставляет вас с ассемблерным кодом.

-c наиболее часто используется, когда у вас есть несколько исходных файлов и вы хотите скомбинировать их для получения итогового исполняемого файла. Так что, вместо такого:

$ gcc -o final-binary test1.c test2.c

будет лучше разделить их так:

$ gcc -c -o test1.o test1.c
 
$ gcc -c -o test2.o test2.c

и затем:

$ gcc -o final-binary ./test1.o ./test1.o

Возможно, вы заметили, что такая же последовательность используется, если вы собираете программу, используя Makefile. Преимущество использования -c ясно: вам нужно перекомпилировать только измененные исходные файлы. Только фаза, на которой переделывается компоновка всех объектных файлов, и это очень экономит время, особенно в больших проектах. Очевидным примером этого является ядро Linux.

-E будет полезна, если вы хотите посмотреть, как ваш код в действительности выглядит после разворачивания макросов, определений и т.п. Возьмите следующий листинг в качестве примера:

#include 
 
#define A 2
 
#define B 4
 
#define calculate(a,b) a*a + b*b
 
void plain_dummy()
 
{
 
    printf("Just a dummyn");
 
}
 
static inline justtest()
 
{
 
    printf("Hi!n");
 
}
 
int main(int argc, char *argv[])
 
{
 
#ifdef TEST
 
    justtest();
 
#endif
 
    printf("%dn", calculate(A,B));
 
    return 0;
 
}

Скомпилируем его следующим образом:

$ gcc -E -o listing2.e listing2.c

Учтите, что мы не указываем параметров -D, что означает, что TEST не определен. Так и что мы имеем в препроцессорном файле?

void plain_dummy()
 
{
 
    printf("Just a dummyn");
 
}
 
static inline justtest()
 
{
 
    printf("Hi!n");
 
}
 
int main(int argc, char *argv[])
 
{
 
    printf("%dn", 2*2 + 4*4);
 
    return 0;
 
}

А где вызов justtest() внутри main()? Нигде. TEST не определен — вот почему код исключен. Вы также можете видеть, что макрос calculate уже развернут в умножение и сложение констант. В конечной исполняемой форме, эти числа будут заменены результатами операций. Как вы видите, -E довольно удобна для проверки корректности директив.

Обратите внимание, что plain_dummy() все ещё здесь, не смотря на то, что она ни разу не вызывается. Это не удивительно, так как ещё не была произведена компиляция, вот почему не произошло исключение «мертвого» кода на этой стадии. stdio.h также развернут, но не показан в листинге выше.

Я нашел интересное приложение использования -E в качестве утилиты создания HTML. Вкратце, она помогает вам перенимать обычные действия в программировании, такие как модуляризация кода и макросы в мир HTML — то, что не может быть сделано на чистом HTML.

-S дает вам код на ассемблере, больше похожий на то, что вы видите с помощью objdump -d/-D. Хотя с помощью -S вы продолжите видеть директивы и имена символов, который делают код проще к изучению. Например, вызов printf(«%dn», 20) может быть трансформирован в:

.section        .rodata.str1.1,"aMS",@progbits,1
 
.LC0:
 
        .string "%dn"
 
...
 
        movl    $20, 4(%esp)
 
        movl    $.LC0, (%esp)
 
        call    printf

Вы можете видеть, что format string %d помещена в область данных, доступную только для чтения (.rodata). Также, вы можете удостовериться, что аргументы помещаются в стек справа налево, со строкой форматирования на верху стека.

Заключение.

gcc дает нам много полезных опций для превращения нашего кода во что угодно. Понимая, что эти опции делают на самом деле, мы можем сделать программу быстрее и ловчее. Хотя, не будьте целиком от них зависимы: вы должны больше внимания уделять написанию эффективного и хорошо структурированного кода.

Благодарности.

Я хочу поблагодарить сообщества на irc каналах OFTC (#kernelnewbies и #gcc) и #osdev (Freenode) за их полезные идеи.

Ссылки

1. Статья в Википедии о Препроцессоре;

2. Статья в Википедии о Компиляторе;

3. Статья в Википедии об Ассемблере;

4. Статья в Википедии о Компоновщике.

5. Пример переупорядочивания кода (англ.);

6. Frame pointer omission (FPO) optimization and consequences when debugging, Часть 1 и Часть 2 (англ.);

7. Описание DWARF (англ.);

8. Описание stabs (англ.);

9. Описание COFF (англ.);

10. Описание XCOFF (варианта COFF) (англ.);

11. Использование препроцессора C в качестве утилиты создания HTML (англ.);

12. Документация по gcc (англ.);

13. AMD Athlon Processor x86 Code Optimization Guide (англ., pdf).