Разработчики Unix традиционно придерживались строгих и разнотипных предпочтений особенно в выборе редакторов.

Доступно множество редакторов, которые легко изучить самостоятельно; наиболее распространенными можно считать vi и Emacs. Оба редактора являются мощными представителями своего типа, чего не скажешь на первый взгляд. У обоих редакторов сравнительно крутая кривая обучения, и они радикально отличаются друг от друга. Emacs является достаточно крупным; он сам себе операционная среда, vi не занимает много места и разработан специально для внедрения в среду Unix. Было написано множество клонов и альтернативных версий каждого редактора, и у самих версий также имеются свои клоны.

В этой книге мы не будем углубляться в изучение vi и Emacs, поскольку материал занял бы слишком много места. В [32] каждому редактору посвящены отдельные главы, кроме того, рекомендуем обратиться к [5] и [17]. В нашей книге мы только сравним Emacs и vi и расскажем, как получить оперативную справку по каждому из них.

Emacs включает исчерпывающий набор руководств, в которых объясняется не только использование Emacs как редактора, но и показывается, как применять Emacs для чтения и отправки электронной почты и новостей в Usenet, для игр (игра гомоку очень даже неплоха) и для ввода команд оболочки. В Emacs, написав полное имя внутренней команды, всегда можно ее выполнить, даже если она не привязана к клавишам.

В отличие от Emacs, документация по vi менее развернутая и менее известна. vi является только редактором, и многие важные команды можно выполнить путем нажатия одной клавиши. Здесь можно переключаться между режимом, в котором при нажатии стандартных букв алфавита они помещаются в текст, и режимом, в котором эти буквы являются командами. Например, можно использовать клавиши h, j, k и l в качестве клавиш управления курсором для навигации по документу.

Оба редактора позволяют создавать макросы для упрощения работы, но их макроязыки очень сильно отличаются. Emacs включает в себя целый язык программирования под названием elisp (Emacs Lisp), который очень тесно связан с языком программирования Common Lisp. В первоначальном варианте vi встроен более спартанский язык, ориентированный на стек. Большинство пользователей просто связывают с клавишами простые однострочные команды vi, но эти команды зачастую запускают программы за пределами vi, чтобы управлять данными внутри vi. По Emacs Lisp написано огромное руководство, включающее пособие по использованию; по языку, встроенному в vi, документация сравнительно скупа.

Некоторые редакторы позволяют смешивать и совмещать функциональности. Так, существуют редакторы, в которых можно использовать Emacs в режиме vi (viper), позволяющем использование стандартных команд vi; в другом клоне vi под названием vile ("vi like Emacs") можно использовать vi в режиме Emacs.

4.1.1. Emacs

Emacs встречается в нескольких вариациях. Первоначальный редактор Emacs был написан Ричардом Столлманом (Richard Stallman), одним из лидеров Фонда свободного ПО (Free Software Foundation — FSF). В течение многих лет его GNU Emacs был самым популярным редактором. С недавних пор популярностью начал пользоваться другой вариант GNU Emacs — XEmacs, в котором больше места уделяется поддержке графического интерфейса. XEmacs начал свою жизнь в качестве Lucid Emacs, набора расширений GNU Emacs, разработанного теперь уже распавшейся компанией Lucid Technologies. В намерения этой компании входило официально включить XEmacs в GNU Emacs. Но из-за технических различий команды не смогли слить свои коды. Несмотря ни на что, эти два редактора отлично совмещаются, а программисты обоих команд заимствуют коды друг у друга. Ввиду того, что обе эти версии очень похожи, в дальнейшем мы будем ссылаться на них как на Emacs.

Лучший способ для удобной работы с редактором Emacs — изучить пособие по работе с ним. Запустите emacs и наберите ^ht. Наберите ^x^c для выхода из Emacs. С помощью обучающей программы можно узнать, где получить дополнительную информацию по Emacs. Здесь вы не узнаете, как получить руководство по Emacs, распространяемое вместе с самим редактором. Для вызова этого руководства наберите ^hi.

Несмотря на то что пользовательский интерфейс Emacs не такой красочный, как некоторые графические среды IDE, в этом редакторе есть множество мощных средств, которые могут понадобиться многим программистам. Например, при использовании Emacs для редактирования кода С. Emacs распознает тип файла и переходит в режим редактирования С, в котором распознается синтаксис С, что может помочь при поиске опечаток. Если вы запускаете компилятор из Emacs, редактор распознает сообщения об ошибках и предупреждениях компилятора, и позволяет перейти на строку с ошибкой при помощи одной команды, даже если для этого придется открыть новый файл. В Emacs также имеется режим отладки: отладчик находится в одном окне и проходит по коду, который вы отлаживаете в другом окне.

4.1.2.

vi

Если вы быстро набираете текст и хотите, чтоб ваши пальцы находились в правильном положении, vi вам наверняка понравится, поскольку его набор команд был разработан таким образом, чтобы движений пальцев печатающего было как можно меньше. Этот редактор также ориентирован на пользователей Unix. Если вы знакомы с sed или awk либо другими программами Unix, использующими стандартные регулярные выражения с ^ для перехода к началу строки и $ для перехода к ее концу, работа с vi покажется вам простой и естественной.

К сожалению, освоение vi может оказаться более сложным, нежели Emacs. Дело в том, что хоть пособия по vi подобны учебникам по Emacs, ни в одной версии vi нет стандартного способа запуска учебного пособия. Тем не менее, многие версии, включая версию, поставляемую с обычными дистрибутивами Linux, поддерживают команду :help.

В наиболее общей версии vi, vim ("Vi IMproved"), есть множество интегрированных средств из набора разработки Emacs, включая выделение синтаксиса, автоматическое расположение текста, язык написания сценариев и разбор ошибок компилятора.

Основой программирования под Unix является make — средство, которое существенно упрощает описание компиляции программ. Даже притом, что небольшим программам порой достаточно одной команды для компиляции их исходного кода в исполняемый файл, все же намного легче написать make, чем строку вроде gcc -02 -ggdb -DSOME DEFINE -о foo foo.c. Более того, если имеется множество файлов для компиляции, а код был изменен лишь в некоторых из них, make создаст новые объектные файлы только для тех файлов, на которые повлияли изменения. Чтобы make совершила это "чудо", потребуется описать все файлы в make-файле (Makefile), пример которого показан ниже.

 1: # Makefile

 2:

 3: OBJS = foo.о bar.о baz.o

 4: LDLIBS = -L/usr/local/lib/ -lbar

 5:

 6: foo: $(OBJS)

 7:       gcc -o foo $ (OBJS) $ (LDLIBS)

 8:

 9: install: foo

10:       install -m 644 foo /usr/bin

11: .PHONY: install

• Строка 1 — это комментарий; make следует обычной традиции Unix определения комментариев с помощью символа #.

• В строке 3 определяется переменная по имени OBJS как foo.о bar.о baz.о.

• В строке 4 определяется другая переменная — LDLIBS.

• В строке 6 начинается определение правила, которое указывает на то, что файл foo зависит от (в этом случае, собран из) файлов, имена которых содержатся в переменной OBJS. foo называется целевым объектом, а $(OBJS) — списком зависимостей. Обратите внимание на синтаксис расширения переменной: имя переменной помещается в $(...).

Строка 7 — это командная строка, указывающая на то, как построить целевой объект из списка зависимостей. Командных строк может быть много, и первым символом в командной строке должна быть табуляция.

• Строка 9 — довольно интересный целевой объект. Фактически тут не предпринимается попытка создать файл по имени install; вместо этого (как видно в строке 10) foo инсталлируется в /usr/bin с помощью стандартной программы install. Эта строка вызывает неоднозначность в make: что, если файл install уже существует и является более новым, нежели foo? В этом случае запуск команды make install приведет к выдаче сообщения 'install' is up to date (install является новее) и завершению работы.

• Строка 11 указывает make на то, что install не является файлом, и что необходимо игнорировать любой файл по имени install при вычислении зависимости install. Таким образом, если зависимость install была вызвана (как это сделать мы рассмотрим далее), команда в строке 10 всегда будет выполняться. .PHONY — это директива, которая изменяет операцию make; в этом случае она указывает make на то, что целевой объект install не является именем файла. Целевые объекты .PHONY часто используются для совершения действий вроде инсталляции или создания одиночного имени целевого объекта, которое основывается на нескольких других уже существующих целевых объектов, например:

all: foo bar baz

.PHONY: all

К сожалению, .PHONY не поддерживается некоторыми версиями make. Менее очевидный, не такой эффективный, но более переносимый способ для этого показан ниже.

all: foo bar baz FORCE

FORCE:

Это срабатывает только тогда, когда нет файла по имени FORCE.

Элементы в списках зависимостей могут быть именами файлов, но, поскольку это касается make, они являются целевыми объектами. Элемент foo в списке зависимости install — это целевой объект. При попытке make вычислить зависимость install становится ясно, что в первую очередь необходимо вычислить зависимость foo. А для этого make потребуется вычислить зависимости foo.о, bar.о и baz.о.

Обратите внимание на отсутствие строк, явно указывающих make, как строить foo.о, bar.о или baz.о. Вы не будете определять эти строки непосредственно в редакторе. make обеспечивает предполагаемые зависимости, которые записывать не нужно. Если в файле есть зависимость, заканчивающаяся на .о, и есть файл с таким же именем, но он заканчивается на .с, make предполагает, что этот объектный файл зависит от исходного файла. Встроенные суффиксные правила, которые поддерживаются make, позволяют значительно упростить многие make-файлы и, если встроенное правило не соответствует требованиям, можно создать свои собственные суффиксные правила (речь об этом пойдет ниже).

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

Аргумент -k заставляет make создавать максимально возможное количество файлов без останова, даже если какая-то команда вернула ошибку. Это полезно, например, при переносе программы; можно построить столько объектных файлов, сколько нужно, а потом перенести файлы, которые вызвали ошибку, без нежелательных перерывов в работе.

Если известно, что какая-то одна команда будет всегда возвращать ошибку, но вы хотите проигнорировать ее, можно воспользоваться "магией" командной оболочки. Команда /bin/false всегда возвращает ошибку, таким образом, /bin/false всегда будет вызывать прекращение работы, если только не указана опция -k. С другой стороны, конструкция любая_команда || /bin/true никогда не вызовет прекращение работы; даже если любая_команда возвращает false, оболочка затем запускает /bin/true, которая вернет успешный код завершения.

make интерпретирует нераспознанные аргументы командной строки, которые не начинаются с минуса (-), как целевые объекты для сборки. Таким образом, make install приводит к сборке целевого объекта install. Если целевой объект foo устарел, make сначала соберет зависимости foo, а затем инсталлирует его. Если требуется собрать целевой объект, начинающийся со знака минус, этот знак перед именем целевого объекта должен быть продублирован (--).

4.2.1 Сложные командные строки

Каждая командная строка выполняется в своей собственной подоболочке, таким образом, команды cd в командной строке влияют только на строку, в которой они записаны. Любую строку в make-файле можно расширить на множество строк, указывая в конце каждой обратный слэш. Ниже показан пример того, как иногда могут выглядеть командные строки.

 1: cd первый_ каталог ; \

 2:   сделать что-то с файлом $ (FOO) ; \

 3:  сделать еще что-то

 4: cd второй_каталог ; \

 5:  if [ -f некоторый_файл ] ; then\

 6:   сделать что-то другое ; \

 7:  done; \

 8:  for i in * ; do \

 9:   echo $$i >> некоторый__файл ; \

10:  done

make находит в этом фрагменте кода только две строки. Первая командная строка начинается в строке 1 и продолжается до строки 3, а вторая начинается в строке 4 и заканчивается в строке 10. Здесь следует отметить несколько моментов.

• второй_каталог является относительным не к каталогу первый_каталог , а к каталогу, в котором запущен make, поскольку эти команды выполняются в разных подоболочках.

• Строки, образующие каждую командную строку, передаются оболочке в виде одной строки. Таким образом, все символы ;, которые нужны оболочке, должны присутствовать, включая даже те, которые обычно в сценариях оболочки опускаются, поскольку их наличие подразумевается благодаря символам новой строки. Более детально о программировании программной оболочки рассказывается в [22].

• Если требуется разыменовывать переменную make, это делается обычным образом (то есть $( переменная ) ), но если нужно разыменовывать переменную оболочки, необходимо применять двойной символ $: $$i.

4.2.2. Переменные

Часто бывает необходимо определить только один компонент переменной за раз. Можно написать, например, такой код:

OBJS = foo.о

OBJS = $(OBJS) bar.о

OBJS = $(OBJS) baz.о

Ожидается, что здесь OBJS будет определен как foo.о bar.о baz.о, но в действительности он определен как $(OBJS) baz.о, поскольку make не разворачивает переменные до момента их использования. При ссылке в правиле на OBJS make войдет в бесконечный цикл. Во избежание этого во многих make-файлах разделы организуются следующим образом:

OBJS1 = foo.о

OBJS2 = bar.о

OBJS3 = baz.о

OBJS = $(OBJS1) $(OBJS2) $(OBJS3)

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

Развертывание переменной вызывает типичный вопрос, который программист в Linux должен решить. Инструменты GNU, распространяемые с Linux, обычно более функциональны, чем версии инструментов, включенных в другие системы, и GNU make — не исключение. Авторы GNU make предусмотрели альтернативный способ присваивания переменных, но не все версии make понимают эти альтернативные формы. К счастью, GNU make можно собрать для любой системы, в которую можно перенести исходный код, написанных под Linux. Существует форма простого присваивания переменных, которая показана ниже.

OBJS := foo.о

OBJS := $(OBJS) bar.о

OBJS := $(OBJS) baz.о

Операция := заставляет GNU make вычислить выражение переменной при присваивании, а не ждать вычисления выражения при его использовании в правиле. В результате выполнения этого кода OBJS действительно получит foo.о bar.о baz.о.

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

OBJS := foo.о

OBJS += bar.о

OBJS += baz.о

4.2.3. Суффиксные правила

Суффиксные правила — это другая область, в которой вам нужно решить, писать ли стандартные make-файлы или использовать расширения GNU. Стандартные суффиксные правила намного ограниченнее, нежели шаблонные правила GNU, но во многих ситуациях стандартные суффиксные правила могут оказаться полезными. К тому же шаблонные правила поддерживаются не во всех версиях make. Суффиксные правила выглядят следующим образом:

.c.o:

$(CC) -с $ (CFLAGS) $ (CPPFLAGS) -о $<

.SUFFIXES: .с .о

В этом правиле говорится (если не касаться излишних деталей), что make должна, если не было других явных указаний, превратить файл а.с в а.о путем запуска приложенной командной строки. Каждый файл .с будет рассматриваться так, будто он явно внесен в список в качестве зависимости соответствующего файла .о в вашем make-файле.

Это суффиксное правило демонстрирует другую возможность make — автоматические переменные. Понятно, что нужно найти способ подставить зависимость и целевой объект в командную строку. Автоматическая переменная $@ выступает в качестве целевого объекта, $< выступает в качестве первой зависимости, а $^ представляет все зависимости.

Существуют и другие автоматические переменные, которые рассматриваются в руководстве по make. Все автоматические переменные можно использовать в обыкновенных правилах, а также в суффиксных и шаблонных правилах.

Последняя строка примера представляет еще одну директиву. .SUFFIXES указывает make на то, что .с и .о являются суффиксами, которые должен использовать make для нахождения способа превратить существующие исходные файлы в необходимые целевые объекты.

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

% .о: % .с

$(CC) -с $(CFLAGS) $(CPPFLAGS) -о $<

Дополнительные сведения о make можно получить в [26]. GNU make также включает замечательное и удобное в обращении руководство в формате Texinfo, которое можно почитать на сайте FSF, распечатать или заказать у них в форме книги.

Большинство крупных проектов с открытым исходным кодом используют инструменты Automake, Autoconf и Libtool. Эти инструменты представляют собой коллекцию знаний об особенностях различных систем и стандартах сообщества, которая может помочь в построении проектов. Таким образом, потребуется писать лишь немного кода, специфического для проекта. Например, Automake пишет целевые объекты install и uninstall, Autoconf автоматически определяет возможности системы и настраивает программное обеспечение для его соответствия системе, a Libtool отслеживает различия в управлении совместно используемыми библиотеками на разных системах.

По этим трем инструментам написана целая книга — [41]; здесь мы даем лишь основу, которая понадобится для работы с GNU Autoconf, Automake и Libtool.

Время от времени вы можете застать себя на том, что просматриваете заголовочные файлы Linux. Скорее всего, вы найдете рад конструкций, не совместимых со стандартом ANSI/ISO. Некоторые из них стоят того, чтобы в них разобраться. Все конструкции, рассматриваемые в этой книге, более подробно изложены в документации по gcc.

5.2.1. long long

Тип long long указывает на то, что блок памяти, по крайней мере, такой же большой, как long. На Intel i86 и других 32-разрядных платформах long занимает 32 бита, а long long — 64 бита. На 64-разрядных платформах указатели и long long занимают 64 бита, a long может занимать 32 или 64 бита в зависимости от платформы. Тип long long поддерживается в стандарте С99 (ISO/IEC 9899:1999) и является давним расширением С, которое обеспечивается gcc.

5.2.2. Встроенные функции

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

5.2.3. Альтернативные расширенные ключевые слова

В gcc у каждого расширенного ключевого слова (ключевые слова, не описанные стандартом ANSI/ISO) есть две версии: само ключевое слово и ключевое слово, окруженное с двух сторон двумя символами подчеркивания. Когда компилятор применяется в стандартном режиме (обычно тогда, когда задействована опция -ansi), обычные расширенные ключевые слова не распознаются. Так, например, ключевое слово attribute в заголовочном файле должно быть записано как __attribute__.

5.2.4. Атрибуты

Расширенное ключевое слово attribute используется для передачи gcc большего объема информации о функции, переменной или объявленном типе, чем это позволяет код С, соответствующий стандарту ANSI/ISO. Например, атрибут aligned дает указание gcc о том, как именно выравнивать переменную или тип; атрибут packed указывает на то, что заполнение использоваться не будет; noreturn определяет то, что возврат из функции никогда не произойдет, что позволяет gcc лучше оптимизироваться и избегать фиктивных предупреждений.

Атрибуты функции объявляются путем их добавления в объявление функции, например:

void die_die_die(int, char*) __attribute__ ((__noreturn__));

Объявление атрибута размещается между скобками и точкой с запятой и содержит ключевое слово attribute, за которым следуют атрибуты в двойных круглых скобках. Если атрибутов много, следует использовать список, разделенный запятыми.

int printm(char*, ...)

__attribute__((const,

 format(printf, 1, 2)));

В этом примере видно, что printm не рассматривает никаких значений, кроме указанных, и не имеет побочных эффектов, относящихся к генерации кода (const), printm указывает на то, что gcc должен проверять аргументы функции так же, как и аргументы printf(). Первый аргумент является форматирующей строкой, а второй — первым параметром замены (format).

Некоторые атрибуты будут рассматриваться по мере дальнейшего изложения материала (например, во время описания сборки совместно используемых библиотек в главе 8). Исчерпывающую информацию по атрибутам можно найти в документации gcc в формате Texinfo.

6.2.1. Обязательные типы POSIX

POSIX описывает некоторые определения типов в заголовочном файле , которые используются для многих аргументов и возвращаемых значений. Эти определения типов важны, потому что стандартные типы языка С могут быть разными на различных машинах, так как они нестрого определены в стандарте С. Из-за такого нестрогого определения язык С полезен на широком диапазоне оборудования — размер слов на 16-разрядных машинах отличается от такового на 64-разрядных машинах, а язык программирования низкого уровня не должен скрывать эту разницу — но для POSIX требуется большая гарантия. От заголовочного файла библиотеки С требуется определение набора соответствующих типов для каждой машины, которая поддерживает POSIX. Каждый из этих определений типов можно легко отличить от собственного типа С, поскольку он заканчивается на _t.

Ниже описано подмножество, используемое для интерфейсов.

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

Кроме того, в будущих версиях Linux представленные типы могут изменяться в рамках, установленных стандартом POSIX.

6.2.2. Раскрытие возможностей времени выполнения

Многие системные возможности имеют ограничения, другие являются необязательными, а некоторые могут содержать связанную с ними информацию. Ограничение на длину строки аргументов, передаваемых новой программе, защищает систему от произвольных запросов памяти, которые в ряде случаев могут вызвать крах системы. Не во всех системах POSIX реализовано управление заданиями. Любая программа может получить сведения о наиболее поздней версии стандарта POSIX, которая реализована в системе.

Функция sysconf() выдает такой тип системной информации, которая для одного и того же исполняемого файла в различных системах может отличаться и которую невозможно узнать во время компиляции.

#include

long sysconf (int);

Целочисленный аргумент в sysconf() — это один из наборов макросов с префиксом _SC_. Ниже перечислены макросы, которые используются чаще всего.

6.2.3. Поиск и настройка базовой системной информации

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

Системный вызов uname() позволяет программе обнаружить информацию времени ее выполнения.

#include

int uname(struct utsname* unameBuf);

В случае ошибки функция возвращает ненулевое значение, что происходит только в ситуациях, когда передается недопустимый указатель unameBuf. При нормальном завершении структура, на которую он указывает, заполняется строками, завершаемыми NULL, которые описывают текущую систему. В табл. 6.1 представлены члены структуры utsname.

Таблица 6.1. Члены структуры utsname

Член nodename (имя узла) часто называется системным именем хоста (то, что отображает команда hostname), однако его не следует путать с именем Internet-хоста. Несмотря на то что во многих системах эти члены не различаются, путать их не стоит. В системе с множеством Internet-адресов есть множество имен Internet-хостов, но только одно имя узла, поэтому эти имена не являются эквивалентными.

Более распространенная ситуация связана с домашними компьютерами, которые используют Internet-каналы широкополосной связи. Обычно их имя хоста в Internet выглядит вроде host127-56.raleigh.myisp.com, а имена Internet-хостов меняются каждый раз при отключении на длительное время от модема. Владельцы этих машин дают своим компьютерам имя узла, которое им больше нравится, например, loren или eleanor, что совершенно не относится к адресам Internet. При наличии множества машин, работающих на одном домашнем шлюзе, все они будут разделять один Internet-адрес (и одно имя Internet-хоста), но могут иметь имена вроде Linux.mynetwork.org и freebsd.mynetwork.org, которые все еще не являются именами Internet-хоста. В связи со всеми вышеперечисленными причинами, предполагать, что имя системного узла является допустимым именем Internet-хоста для машины не верно.

Имя узла системы устанавливается с помощью системного вызова sethostname(), и имя домена NIS (YP) — посредством системного вызова setdomainname().

#include

int sethostname(const char * name, size_t len);

int setdomainname(const char * name, size_t len);

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

Библиотека GNU С (glibc) предлагает три простых средства проверки памяти. Первые два — mcheck() и MALLOC_CHECK_ — вызывают проверку на непротиворечивость структуры данных кучи, а третье средство — mtrace() — выдает трассировку распределения и освобождения памяти для дальнейшей обработки.

7.2.1. Поиск повреждений кучи

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

Если вы установили переменную окружения MALLOC_CHECK_, выбирается другой, несколько более медленный набор функций управления памятью. Этот набор более устойчив к ошибкам и может обнаруживать ситуации, когда free() вызывается более одного раза для одного и того же указателя, а также когда происходят однобайтные переполнения буфера. Если MALLOC_CHECK_ установлена в 0, функции управления памятью просто более устойчивы к ошибкам, но не выдают никаких предупреждений. Если MALLOC_CHECK_ установлена в 1, функции управления памятью выводят предупреждения о стандартных ошибках при замеченной проблеме. Если MALLOC_CHECK_ установлена в 2, функции управления памятью вызывают abort(), когда замечают проблемы.

Установка MALLOC_CHECK_ в 0 может оказаться полезной, если вам мешает найти ошибку в памяти другая ошибка, которую в этот момент исправить нет возможности; эта установка позволяет работать с другими средствами отслеживания ошибок памяти.

Установка MALLOC_CHECK_ в 1 полезна в случае, когда никаких проблем не видно, поэтому определенные уведомления могут помочь.

Установка MALLOC_CHECK_ в 2 наиболее полезна при работе в отладчике, поскольку при возникновении ошибки он позволяет выполнить обратную трассировку вплоть до функций управления памятью. В результате вы максимально приблизитесь к месту возникновения ошибки.

$ MALLOC_CHECK_=1 ./broken

malloc: using debugging hooks

malloc: используются отладочные функции

1: 12345

free(): invalid pointer 0x80ac008!

free(): недопустимый указатель 0x80ac008!

2: 12345678

3: 12345678

4: 12345

5: 12345

6: 12345

7: 12345

$ MALLOC_CHECK_=2 gdb ./broken

...

(gdb) run

Starting program: /usr/src/lad/code/broken

Запуск программы: /usr/src/lad/code/broken

1: 12345

Program received signal SIGABRT, Aborted.

Программа получила сигнал SIGABRT, прервана.

0x00 с 64 с 32 in _dl_sysinfo_int80() from/lib/ld-linux.so.2

(gdb) where

#0 0x00c64c32 in _dl_sysinfo_int80() from /lib/ld-linux.so.2

#1 0x00322969 in raise() from /lib/tls/libc.so.6

#2 0x00324322 in abort() from /lib/tls/libc.so.6

#3 0x0036d9af in free_check() from /lib/tls/libc.so.6

#4 0x0036afa5 in free() from /lib/tls/libc.so.6

#5 0x0804842b in broken() at broken.c:17

#6 0x08048520 in main() at broken.с:47

Другой способ заставить glibc проверить кучу на непротиворечивость — воспользоваться функцией mcheck():

typedef void(*mcheck Callback)(enummcheck_status status);

void mcheck(mcheck Callback cb) ;

В случае вызова функции mcheck(), функция malloc() размещает известные последовательности байтов перед и после возвращенной области памяти, чтобы можно было обнаружить переполнение или недогрузку буфера, free() ищет эти сигнатуры и, если они были повреждены, вызывает функцию, указанную аргументом cb. Если cb равен NULL, выполняется выход. Запуск программы, связанной с mcheck(), в gdb может показать, какие именно области памяти были повреждены, если только они явно освобождаются с помощью free(). Однако метод mcheck() не может точно определить место ошибки; лишь программист может вычислить это, основываясь на понимании логики работы программы.

Компоновка нашей тестовой программы с mcheck дает следующие результаты:

$ gcc -ggdb -о broken broken.с -lmcheck

$ ./broken

1: 12345

memory clobbered past end of allocated block

память разрушена после конца распределенного блока

Вследствие того, что mcheck всего лишь выдает сообщения об ошибках и завершает работу, найти ошибку невозможно. Для точного обнаружения ошибки потребуется запустить программу внутри gdb и заставить mcheck вызывать abort() при обнаружении ошибки. Можно просто вызвать mcheck() внутри gdb или поместить mcheck(1) в первой строке вашей программы (веред вызовом malloc()). (Следует отметить, что mcheck() можно вызвать в gdb без необходимости компоновки программы с библиотекой mcheck.)

$ rm -f broken; make broken

$ gdb broken

...

(gdb) break main

Breakpoint 1 at 0x80483f4: file broken.c, line 14.

Точка прерывания 1 по адресу 0x80483f4: файл broken, с, строка 14.

(gdb) command 1

Type commands for when Breakpoint 1 is hit, one per line.

End with a line saying just "end".

Наберите команды, которые выполнятся при достижении точки прерывания 1, по одной в строке.

Завершите строкой, содержащей только "end".

> call mcheck(&abort)

> continue

> end (gdb) run

Starting program: /usr/src/lad/code/broken

Запуск программы: /usr/src/lad/code/broken

Breakpoint 1, main () at broken.с: 14

47 return broken();

$1 = 0

1: 12345

Program received signal SIGABRT, Aborted.

Программа получила сигнал SIGABRT, прервана.

0x00e12c32 in _dl_sysinfo_int80() from /lib/ld-linux.so.2

(gdb) where

#00x00el2c32 in _dl_sysinfo_int80() from /lib/ld-linux.so.2

#1 0x0072c969 in raise() from /lib/tls/libc.so.6

#2 0x0072e322 in abort() from /lib/tls/libc.so.6

#3 0x007792c4 in freehook() from /lib/tls/libc.so.6

#4 0x00774fa5 in free() from /lib/tls/libc.so.6

#5 0x0804842b in broken() at broken.c:17

#6 0x08048520 in main() at broken.с:47

Важной частью этого кода является обнаруженная ошибка в строке 17 файла broken.с. Видно, что ошибка была обнаружена во время первого вызова free(), который указал на наличие проблемы в области памяти dyn. (freehook() представляет собой ловушку, с помощью которой mcheck выполняет проверки.)

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

7.2.2. Использование

mtrace()

для отслеживания распределений памяти

Один из простых способов нахождения всех утечек памяти в программе предусматривает регистрацию всех вызовов malloc() и free(). По окончании программы очень легко сопоставить блоки, распределенные через malloc(), с точками, где они были освобождены с помощью free() или сообщить об ошибке, если для какого-то блока free() не вызывалась.

В отличие от mcheck(), в mtrace() нет соответствующей библиотеки для компоновки. Это не проблема, поскольку трассировку можно осуществлять в gdb. Однако для включения трассировки с помощью mtrace() должна быть установлена переменная окружения MALLOC_TRACE в допустимое имя файла; это может быть либо имя существующего файла, в который процесс может вести запись, либо имя нового файла, который процесс создаст и будет в него записывать.

$ MALLOC_TRACE=mtrace.log gdb broken

...

(gdb) breakmain

Breakpoint 1 at 0x80483f4: filebroken.c, line 14.

(gdb) command 1

Type commands for when Breakpoint 1 is hit, one per line.

End with a line saying just "end".

>call mtrace()

>continue

>end

(gdb) run

Starting program: /usr/src/lad/code/broken

Breakpoint 1, main() at broken.с:47

47 return broken();

$1 = 0

1: 12345

2: 12345678

3: 12345678

4: 12345

5: 12345

6: 12345

7: 12345

Program exited normally.

Программа завершена нормально.

 (gdb) quit

$ ls -l mtrace.log

-rw-rw-r-- 1 ewt ewt 220 Dec 27 23:41 mtrace.log

$ mtrace ./broken mtrace.log

Memory not freed:

He освобождена память:

----------------------

   Address   Size Caller

     Адрес Размер Место вызова

0x09211378    0x5 at /usr/src/lad/code/broken.с:20

Обратите внимание, что программа mtrace точно обнаружила утечку памяти. Также она может найти факт освобождения с помощью free() памяти, которая ранее не распределялась, если этот факт будет зафиксирован в журнальном файле, но на практике так не происходит, поскольку в этом случае программа немедленно аварийно завершается.

Следующее средство, которое мы рассмотрим — это Electric Fence (доступен на ftp://sunsite.unc.edu/pub/Linux/devel/lang/c и во многих дистрибутивах). Несмотря на то что Electric Fence не обнаруживает утечки памяти, он очень помогает в изоляции переполнений буфера. Каждый современный компьютер (включая все машины, работающие под Linux) обеспечивают аппаратную защиту памяти. Linux этим пользуется для изоляции программ друг от друга (например, сеанс vi не имеет доступа к памяти gcc) и для безопасного разделения кода между процессами, делая его только для чтения. Системный вызов mmap() в Linux (см. главу 13) позволяет процессу воспользоваться также аппаратной защитой памяти.

Electric Fence заменяет обычную функцию malloc() библиотеки С версией, которая распределяет запрошенную память и (обычно) непосредственно после запрошенной выделяет фрагмент памяти, доступ к которой процессу не разрешен. Если процесс попытается получить доступ к этой памяти, ядро немедленно остановит его с выдачей ошибки сегментации. За счет такого распределения памяти Electric Fence обеспечивает уничтожение программы, если та предпримет попытку чтения или записи за границей буфера, распределенного malloc(). Детальную информацию по использованию Electric Fence можно прочитать на его man-странице (man libefence).

7.5.1. Использование Electric Fence

Одна из наиболее примечательных особенностей Electric Fence заключается в простоте ее использования. Нужно всего лишь скомпоновать свою программу с библиотекой libefence.а, указав -lefence в качестве последнего аргумента. В результате код будет готов к отладке. Давайте посмотрим, что происходит при запуске тестовой программы с применением Electric Fence.

$ ./broken

Electric Fence 2.2.0 Copyright (C) 1987 - 1999 Bruce Perens.

1: 12345

Segmentation fault (core dumped)

Ошибка сегментации (дамп ядра сброшен)

Хотя Electric Fence непосредственно не указывает на место, где произошла ошибка, проблема становится намного очевидней. Можно легко и точно определить проблемный участок, запустив программу под управлением отладчика, например gdb. Для того чтоб gdb смог точно указать на проблему, соберите программу с отладочной информацией, указав для gcc флажок -g, затем запустите gdb и зададите имя исполняемого файла, который нужно отладить. Когда программы уничтожается, gdb точно показывает, в какой строке произошел сбой.

Вот как выглядит описанная процедура.

$ gcc -ggdb -Wall -о broken broken.с -lefence

$ gdb broken

...

(gdb) run

Starting program: /usr/src/lad/code/broken

Electric Fence 2.2.0 Copyright (C) 1987 - 1999 Bruce Perens.

1: 12345

Program received signal SIGSEGV, Segmentation fault.

Программа получила сигнал SIGSEGV, ошибка сегментации.

0х007948с6 in strcpy() from /lib/tls/libc.so.6

(gdb) where

#0 0x007948c6 in strcpy() from /lib/tls/libc.so.6

#1 0x08048566 in broken() at broken.c:21

#2 0x08048638 in main() at broken.c:47

(gdb)

Благодаря Electric Fence и gdb, становится понятно, что в строке 21 файла broken.с имеется ошибка, связанная со вторым вызовом strcpy().

7.5.2. Выравнивание памяти

Хотя инструмент Electric Fence очень помог в обнаружении второй проблемы в коде, а именно — вызова strcpy(), переполнившего буфер, первое переполнение буфера найдено не было.

Проблему в этом случае нужно решать с помощью выравнивания памяти. Большинство современных компьютеров требуют, чтобы многобайтные объекты начинались с определенных смещений в оперативной памяти. Например, процессоры Alpha требуют, чтобы 8-байтовый тип — длинное целое (long) — начинался с адреса, кратного 8. Это значит, что длинное целое может располагаться по адресу 0x1000 или 0x1008, но не 0x1005.

На основе этих соглашений реализации malloc() обычно возвращают память, первый байт которой выровнен в соответствии с размером слова процессора (4 байта для 32-разрядных и 8 байтов на 64-разрядных процессоров). По умолчанию Electric Fence пытается эмулировать такое поведение, предлагая функцию malloc(), возвращающую только адреса, кратные sizeof(int).

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

В случае с нашей тестовой программой первый вызов malloc() распределил пять байт.

Для того чтобы Electric Fence удовлетворял своим ограничениям по выравниванию, он трактует этот вызов как запрос восьми байт, с дополнительными тремя доступными байтами. В этом случае небольшие переполнения буфера, распространяющиеся на эту область, не перехватываются.

В связи с тем, что выравнивание malloc() обычно можно игнорировать, а выравнивание может способствовать незаметному переполнению буфера, Electric Fence предоставляет возможность управление выравниванием через переменную окружения ЕF_ALIGNMENT. Если эта переменная установлена, все результаты malloc() выравниваются в соответствии с ее значением. Например, если переменная установлена в значение 5, все результаты malloc() будут рассматриваться как кратные 5 (тем не менее, это значение не особенно полезно). Для отключения выравнивания памяти перед запуском программы установите ЕF_ALIGNMENT в 1. В среде Linux некорректно выровненный доступ в любом случае исправляются в ядре, несмотря на то, что в результате скорость выполнения программы может существенно снизиться. Программа будет функционировать корректно, если только в ней не присутствуют небольшие переполнения буфера.

Ниже приведен пример поведения тестовой программы, скомпонованной с Electric Fence, после установки ЕF_ALIGNMENT в 1.

$ export EF_ALIGNMENT=1

$ gdb broken

...

(gdb) run

Starting program: /usr/src/lad/code/broken

Electric Fence 2.2.0 Copyright (C) 1987 - 1999 Bruce Perens.

Program received signal SIGSEGV, Segmentation fault.

0x002a78c6 in strcpy() from /lib/tls/libc.so.6

(gdb) where

#0 0x002a78c6 in strcpy() from /lib/tls/libc.so.6

#1 0x08048522 in broken() at broken.c:15

#2 0x08048638 in main() at broken.с:47

На этот раз Electric Fence нашел переполнение буфера, которое произошло первым.

7.5.3. Другие средства

Electric Fence не только помогает обнаружить переполнение буфера, но и может найти недогрузку буфера (выполняя доступ к памяти, расположенной перед началом выделяемого malloc() буфера) и получает доступ к памяти, освобождаемой с помощью free(). Если переменная окружения EF_PROTECT_BELOW установлена в 1, Electric Fence перехватывает недогрузку буфера вместо его переполнения. Это происходит путем размещения недоступной области памяти непосредственно перед фактической областью памяти, возвращаемой функцией malloc(). При этом Electric Fence не сможет обнаружить переполнение буфера из-за страничной организации памяти, реализованной в большинстве процессоров. Выравнивание памяти может затруднить обнаружение переполнения буфера, однако оно не влияет на недогрузку буфера. Функция malloc() из Electric Fence всегда возвращает адрес памяти в начале страницы, которая всегда выровнена по границе слова.

Если EF_PROTECT_FREE установлена в 1, free() делает переданную ей область памяти недоступной, но не возвращает ее в пул свободной памяти. Если программа пытается получить доступ к этой памяти на любом этапе в будущем, ядро обнаружит несанкционированный доступ. Настройка EF_PROTECT_FREE помогает удостовериться, что код ни на одном этапе выполнения не использует память, освобожденную с помощью free().

7.5.4. Ограничения

Несмотря на то что Electric Fence выполняет неплохую работу по обнаружению переполнения буферов, выделенных malloc(), он не помогает отслеживать проблемы ни с глобальными, ни с локальными данными. Electric Fence также не обнаруживает утечки памяти, потому решать эту проблему придется другими средствами.

7.5.5. Потребление ресурсов

Хотя Electric Fence является мощным, легким в употреблении и быстрым инструментом (поскольку все проверки доступа осуществляются аппаратными средствами), за все это приходится платить свою цену. Большинство процессоров позволяют системе управлять доступом к памяти только в единицах, равных странице, за один раз. На процессорах Intel 80x86, например, каждая страница занимает 4096 байт. Вследствие того, что Electric Fence требует от malloc() установки двух разных областей памяти для каждого вызова (одна — позволяющая доступ, а другая — запрещающая), каждый вызов malloc() потребляет страницу памяти, или 4 Кбайт! Если в тестируемом коде распределяется множество небольших участков памяти, его компоновка с Electric Fence может легко увеличить потребление памяти программы на два или три порядка. При этом использование EF_PROTECT_FREE еще более усугубляет положение, поскольку память никогда не освобождается.

Для систем с большими относительно размера отлаживаемой программы объемами памяти при поиске источника определенной проблемы Electric Fence может действовать быстрее, чем Valgrind. Тем не менее, если для функционирования Electric Fence требуется организовать пространство для свопинга размером в 1 Гбайт, то Valgrind, вполне вероятно, окажется намного быстрее, даже несмотря на то, что он использует эмулятор, а не собственно центральный процессор.

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

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

8.3.1. Управление совместимостью

Каждой совместно используемой библиотеке Linux присваивается специальное имя, называемое soname, которое включает имя библиотеки и номер ее версии. При изменении интерфейсов в имени библиотеки изменяется номер версии. В некоторых библиотеках нет стабильных интерфейсов; разработчики меняют их так, что они перестают быть совместимыми со старой версией, которая отличается лишь младшим номером версии. Большинство разработчиков стараются поддерживать постоянные интерфейсы, которые при изменении перестают быть совместимыми только тогда, когда выходит библиотека с новым старшим номером версии.

Например, разработчики и службы поддержки библиотеки С в Linux стараются поддерживать обратную совместимость для всех выпусков библиотеки С с одним и тем же старшим номером версии. Версия 5 библиотеки С прошла через пять небольших ревизий и, за некоторыми исключениями, программы, работающие с первой младшей версией, будут работать и с последней. (Исключения составляют неудачно написанные программы, основанные на неопределенном поведении библиотеки С или библиотеке С с ошибками, которые были исправлены в более новых версиях.) Ввиду того, что все библиотеки С версии 5 рассчитаны на обратную совместимость с предыдущими версиями, все они используют одно и то же имя soname — libc.so.5, относящееся к имени файла, в котором оно хранится — /lib/libc.so.5. m.r , где m — младший номер версии, a r — номер выпуска.

Приложения, которые компонуются с совместно используемой библиотекой, не компонуются непосредственно, например, с /lib/libc.so.6, даже если этот файл существует. Программа ldconfig, стандартная системная утилита, создает символическую ссылку /lib/libc.so.6 (soname) на /lib/libc-2.3.2.so, действительное имя библиотеки.

В результате упрощается модернизация совместно используемых библиотек. Для обновления версии 2.3.2 до 2.3.3 потребуется всего лишь скопировать новую версию libc-2.3.3.so в каталог /lib и запустить ldconfig. ldconfig просматривает все библиотеки с soname, равным libc.so.6, и создает символическую ссылку из soname на самую новую библиотеку, включающую это soname. Затем все приложения, скомпонованные с /lib/libc.so.6, автоматически используют новую библиотеку при последующих запусках, a /lib/libc-2.3.2.so можно смело удалить, поскольку потребность в ней полностью отпадает.

Не компонуйте программы со специфическими версиями библиотеки, если на то нет веских причин. Всегда используйте стандартную опцию -l имя_библиотеки компилятора или компоновщика. Таким образом, вы никогда не скомпонуете по ошибке приложение с неправильной версией. Компоновщик всегда будет искать файл lib имя_библиотеки .so , который будет символической ссылкой на новую версию библиотеки.

Итак, для компоновки с библиотекой С компоновщик находит /usr/lib/libc.so, указывающую на то, что нужно использовать /lib/libc.so.6, который является ссылкой на /lib/libc-2.3.2.so. Приложение компонуется с soname-именем libc-2.3.2.so — libc.so.6, и при запуске оно находит /lib/libc.so.6 и связывается с libc-2.3.2.so, поскольку libc.so.6 является символической ссылкой на libc-2.3.2.so.

8.3.2. Несовместимые библиотеки

Если новая версия библиотеки не должна быть совместимой с предшествующими ее версиями, ей потребуется присвоить другое имя soname. Например, для выпуска новой версии библиотеки С, не совместимой со старой версией, разработчики использовали soname libc.so.6 вместо libc.so.5. В результате делается акцент на несовместимости, а приложения, скомпонованные с разными версиями библиотеки, могут сосуществовать в одной системе. Приложения, скомпонованные с одной из версий libc.so.5, будут продолжать использовать последнюю версию библиотеки с soname libc.so.5, а приложения, скомпонованные с одной из версий libc.so.6, будут работать с последней версией библиотеки, соответствующей soname libc.so.6.

8.3.3. Разработка совместимых библиотек

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

1. Изменение или удаление интерфейсов экспортированных функций.

2. Изменение экспортированных элементов данных, исключая добавление необязательных элементов в конец структур, размещенных внутри библиотеки.

3. Изменение поведения функций, выходящее за пределы первоначальной спецификации.

Для поддержания совместимости версий библиотеки можно предпринимать следующие действия.

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

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

Программа ldconfig выполняет всю рутинную работу по инсталляции совместно используемых библиотек. Вам всего лишь нужно получить файлы и запустить ldconfig. Выполните описанные ниже шаги.

1. Скопируйте совместно используемую библиотеку в каталог, в котором она должна быть сохранена.

2. Если нужно, чтоб компоновщик смог найти библиотеку без указания ее с помощью флажка -L библиотека , инсталлируйте библиотеку в /usr/lib или создайте символическую ссылку в /usr/lib по имени имя_библиотеки .so , которая указывает на файл совместно используемой библиотеки. Вы должны использовать относительную символическую ссылку (когда /usr/lib/libc.so указывает на ../../lib/libc.so.5.3.12), а не абсолютную (когда /usr/lib/libc.so указывает на /lib/libc.so.5.3.12).

3. Если нужно, чтобы компоновщик смог обнаружить библиотеку без ее инсталляции в системе (или до ее инсталляции), создайте ссылку имя_библиотеки .so в текущем каталоге. Затем используйте -L., чтоб указать gcc на поиск библиотек в текущем каталоге.

4. Если полный путь к каталогу, в который вы инсталлировали файл совместно используемой библиотеки, не перечислен в /etc/ld.so.conf, добавьте его в этот файл, указав в отдельной строке.

5. Запустите программу ldconfig, которая создаст в каталоге, где инсталлирован файл совместно используемой библиотеки, еще одну символическую ссылку из имени soname на установленный файл. Затем в кэше динамического загрузчика появится соответствующая запись. В результате динамический загрузчик сможет найти вашу библиотеку при запуске скомпонованных с нею программ, не проводя поиск ее во множестве каталогов.

Создавать записи в /etc/ld.so.conf и запускать ldconfig нужно только тогда, когда библиотеки инсталлируются в качестве системных.

8.5.1. Пример

В качестве очень простого, но все же информативного примера создадим библиотеку, содержащую одну короткую функцию. Ниже показано содержимое файла libhello.c.

1: /* libhello.c */

2:

3: #include

4:

5: void print_hello (void) {

6:  printf("Добро пожаловать в библиотеку!\n");

7: }

Разумеется, необходима программа, которая использует библиотеку libhello.

1: / * usehello.c * /

2:

3: #include "libhello.h"

4:

5: int main(void) {

6:  print_hello();

7:  return 0;

8: }

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

1. С использованием флажка -fPIC соберите объектный файл совместно используемой библиотеки:

gcc -fPIC -Wall -g -с libhello.c

2. Скомпонуйте libhello с библиотекой С для достижения лучших результатов во всех системах:

gcc -g -shared -Wl, -soname,libhello.so.0 -о libhello.so.0.0 libhello.о -lc

3. Создайте ссылку из soname на библиотеку:

ln -sf libhello.so.0.0 libhello.so.0

4. Создайте ссылку для использования компоновщиком при компиляции приложений с опцией -lhello:

ln -sf libhello.so.0 libhello.so

5. С помощью флажка -L. укажите компоновщику на необходимость поиска библиотек в текущем каталоге, а с помощью -lhello определите, с какой библиотекой выполнять компоновку:

gcc -Wall -g -с usehello.c -о usehello.o

gcc -g -о usehello usehello.o -L. -lhello

(В этом случае приложение будет компоноваться, даже если вы инсталлируете библиотеку в системе вместо того, чтобы оставить ее в текущем каталоге.)

6. Теперь запустите usehello:

LD_LIBRARY_PATH=$(pwd) ./usehello

Переменная окружения LD_LIBRARY_PATH указывает системе места, где следует искать библиотеки (более детальная информация представлена в следующем разделе). Конечно, по желанию можно установить libhello.so.* в /usr/lib и избежать настройки переменной окружения LD_LIBRARY_PATH.

Самый легкий способ работы с совместно используемыми библиотеками — игнорировать тот факт, что она совместная. Компилятор С автоматически задействует совместно используемые библиотеки вместо статических, если ему явно не указано обратное.

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

8.6.1. Использование деинсталлированных библиотек

После запуска программы динамический загрузчик обычно ищет необходимые программе библиотеки в кэше (/etc/ld.so.cache, созданном ldconfig) библиотек, которые находятся в каталогах, записанных в /etc/ld.so.conf. Однако если установлена переменная окружения LD_LIBRARY_PATH, поиск осуществляется сначала в каталогах, перечисленных в ней. Это значит, что если вы хотите использовать измененную версию библиотеки С при работе с определенной программой, эту библиотеку можно поместить в любой каталог и соответствующим образом изменить LD_LIBRARY_PATH. Например, некоторые версии браузера Netscape, скомпонованные с версией 5.2.18 библиотеки С, не будут работать вследствие ошибки сегментации при запуске со стандартной библиотекой С 5.3.12. Это происходит из-за более строгой политики malloc(). Многие помещают копию библиотеки С 5.2.18 в отдельный каталог, например, /usr/local/netscape/lib/, переносят туда исполняемый файл браузера Netscape и заменяют /usr/local/bin/netscape сценарием оболочки, который выглядит примерно так:

#!/bin/sh

export LD_LIBRARY_PATH=/usr/local/netscape/lib:$LD_LIBRARY_PATH

exec /usr/local/netscape/lib/netscape $*

8.6.2. Предварительная загрузка библиотек

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

Пример может служить zlibc. Эта библиотека заменяет файловые функции библиотеки С функциями, которые работают со сжатыми файлами. При открытии файла zlibc ищет как запрашиваемый файл, так и gzip-версию файла. Если запрашиваемый файл существует, zlibc в точности воспроизводит функцию библиотеки С, но если файла нет, а вместо него обнаруживается gzip-версия, библиотека распаковывает gzip-файл безо всякого уведомления приложения. Связанные с ней ограничения описаны в документации, zlibc позволяет значительно увеличить количество свободного пространства на диске, разумеется, за счет снижения скорости. Существуют два способа предварительной загрузки библиотеки. Для действия только на определенные программы, можно установить переменную окружения для необходимых случаев:

LD_PRELOAD=/lib/libsomething.o exec /bin/someprogram $*

Кроме того, как и с zlibc, может возникнуть потребность предварительно загрузить библиотеку для всех программ в системе. Самый простой способ для этого — добавить в файл /etc/ld.so.preload строку, которая указывает библиотеку, подлежащую загрузке. Для случая zlibc строка будет выглядеть следующим образом:

/lib/uncompress.о

В этой книге практически повсеместно упоминаются системные вызовы, которые являются фундаментальными для программного окружения. На первый взгляд, они выглядят как обычные вызовы функций С. И это не случайно; они представляют собой специальную разновидность вызовов функций. Чтобы понять различия, нужно иметь общее представление о структуре операционной системы. Несмотря на то что операционная система Linux состоит из множества фрагментов кода (утилиты, библиотеки, приложения, программные библиотеки, драйверы устройств, файловые системы, управление памятью и так далее), все эти кодовые фрагменты работают в одном из двух контекстов: режиме пользователя или режиме ядра.

При разработку программы написанный код работает в режиме пользователя (user mode). Драйверы устройств и файловые системы, наоборот, работают в режиме ядра (kernel mode). В пользовательском режиме программы тщательно защищены от повреждений, вызванных их взаимодействием друг с другом или остальной частью системы. Код, работающий в режиме ядра, имеет полный доступ к компьютеру и может делать или же разрушать все, что угодно.

Драйвер, который разработан для управления и контроля аппаратного устройства, должен иметь полный доступ к нему. Устройство нужно защитить от случайных программ, чтобы они не смогли нарушить свою работу или работу друг друга, повредив само устройство. Память, с которой работает устройство, также защищена от случайных программ. Весь код, работающий в режиме ядра, существует исключительно для обслуживания кода, который работает в режиме пользователя. Системный вызов — это то, посредством чего код приложения, выполняющегося в пользовательском режиме, запрашивает службу, предоставляемую кодом, который выполняется в режиме ядра.

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

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

9.2.1. Ограничения системных вызовов

Режим ядра защищен от влияния режима пользователя. Одна из таких защит состоит в том, что тип данных, передаваемых между режимами ядра и пользователя, ограничен, легко верифицируется и следует строгим соглашениям.

• Длина каждого аргумента, передаваемого из режима пользователя в режим ядра, практически всегда соответствует размеру слов, используемых машиной для представления указателей. Этого размера достаточно как для передачи указателей, так и длинных целых. Переменные типа char и short перед передачей расширяются до большего типа.

• Тип возвращаемого значения ограничен размером слова со знаком. Первые несколько сотен небольших отрицательных целых чисел зарезервированы в качестве кодов ошибок, и в пределах системных вызовов имеют одинаковое значение. Это значит, что системные вызовы, возвращающие указатель, не могут вернуть некоторые указатели, соответствующие адресам в верхней области доступной виртуальной памяти. К счастью, эти адреса находятся в зарезервированном пространстве и в любом случае никогда не возвращаются, потому возвращаемые слова со знаком могут быть без проблем преобразованы в указатели.

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

9.2.2. Коды возврата системных вызов

Коды возврата, зарезервированные для всех системных вызовов — это универсальные коды возврата ошибок, представленные небольшими отрицательными числами. Библиотека С проверяет наличие ошибок каждый раз, когда происходит системный вызов. При возникновении ошибки библиотека помещает значение ошибки в глобальную переменную errno. В большинстве случаев все, что вам необходимо при проверке ошибки — посмотреть, отрицательный ли код возврата. Коды ошибок определены в , и errno можно сравнить с любым номером ошибки из этого файла, после чего обработать ее специальным образом.

Переменная errno используется и в другом случае. Библиотека С предлагает три способа получения строк, предназначенных для описания возникшей ошибки.

perror()

Печатает сообщение об ошибке. Передайте в функцию строку с информацией о том, что код намеревался предпринять.

if ((file = open(DB_PATH, O_RDONLY)) < 0) {

 perror("не удается открыть файл базы данных");

}

Функция perror() выведет сообщение, описывающее возникшую ошибку, а также объяснение того, что код собирался делать:

не удается открыть файл базы данных: No such file or directory

Обычно неплохо делать свои аргументы для perror() уникальными на протяжении всей программы, в результате при получении сообщений об ошибках из perror() вы будете точно знать, откуда начинать поиск. Обратите внимание, что в строке, передаваемой perror(), нет символа новой строки. Его передавать не нужно — функция сама его выведет.

strerror()

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

if ((file = open(DB_PATH, O_RDONLY) ) < 0) {

 fprintf(stderr,

  "не удается открыть файл базы данных %s, %s\n",

  DB_PATH, strerror(errno));

}

sys_errlist

He очень хорошая альтернатива strerror(). sys_errlist — это массив размером sysnerr указателей на статические, доступные только для чтения символьные строки, которые описывают ошибки. Попытка записи в эти строки приводит к нарушению сегментации и сбросу дампа ядра.

if ((file = open(DB_PATH, O_RDONLY)) < 0) {

 if (errno < sys_nerr) {

  fprintf(stderr,

   "не удается открыть файл базы данных %s, %s\n",

   DB_PATH, sys_errlist[errno]);

 }

}

Этот массив не является ни стандартным, ни переносимым, и упоминается здесь лишь потому, что вы можете столкнуться с кодом, от него зависящим. Заменив такой код вызовом функции strerror(), вы получите существенный выигрыш.

Если вы не собираетесь использовать errno сразу же после генерации ошибки, сохраните ее копию. Любая библиотечная функция может установить errno в любое значение, поскольку в ней могут присутствовать системные вызовы, о которых вы даже не подозреваете. А некоторые библиотечные функции могут устанавливать errno даже без системных вызовов.

9.2.3. Использование системных вызовов

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

Большинство, но не все, системные вызовы объявлены в . Фактически файл представляет собой универсальное вместилище практически для всех системных вызовов. Чтобы определить, какие включаемые файлы нужно использовать, обычно нужно обратиться к системным man-страницам. Хотя описания функций на man-страницах зачастую весьма лаконичны, там можно найти точные указания о том, какой файл должен быть включен для использования функции.

Есть одна особенность, свойственная системам Unix. Системные вызовы документированы в отдельном разделе man-страниц для библиотечных функций, и вы будете использовать библиотечные функции для доступа к системным вызовам. Там, где библиотечные функции отличаются от системных вызовов, предусмотрены отдельные man- страницы. Это не вызывало бы проблем, однако практически всегда требуется читать страницу, описывающую библиотечную функцию, номер которой больше номера страницы с описанием соответствующего системного вызова. Ввиду того, что man-страницы выводятся, начиная с меньших номеров, приходится проделывать лишнюю работу.

Простого указания номера раздела недостаточно. Системные вызовы, которые помещены в минимальные функции-оболочки из библиотеки С, не документированы как часть библиотеки, следовательно команда man 3 функция не найдет их. Для того чтобы убедиться, что вы прочли всю необходимую для вас информацию, вначале взгляните на man-страницу, не указывая раздел. Если это раздел 2 на man-странице, посмотрите, есть ли там раздел 3 с таким же именем. Если открывается раздел 1 man-страницы, как это часто случается, внимательно просмотрите разделы 2 и 3.

К счастью, существует другой способ решения такой проблемы. Многие версии программы man, включая используемую в системах Linux, позволяют указывать альтернативный путь поиска man-страниц. Прочтите man-страницу о самой программе man, чтобы определить, поддерживается ли в вашей версии man переменная окружения MANSECT и аргумент -S. Если переменная поддерживается, можно установить MANSECT в что-нибудь вроде 3:2:1:4:5:6:7:8:tcl:n:l:p:о. Просмотрите в файле конфигурации man (в большинстве систем Linux это /etc/man.config) текущую настройку MANSECT.

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

if (ioctl(fd, FN, data)) {

 /* обработка ошибки на основе errno */

}

Часто встречается следующая форма:

if (ioctl(fd, FN, data) < 0) {

 /* обработка ошибки на основе errno */

}

Для системных вызовов, которые возвращают 0, обозначая успех, оба эти случая идентичны. В своем коде можете выбрать то, что вам больше подходит. Будьте готовы к тому, что столкнетесь с этими и другими способами обработки в чужих кодах.

9.2.4. Общие коды возврата ошибок

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

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

Для определения того, какую ошибку можно ожидать от определенного системного вызова, обращайтесь к соответствующим man-страницам. В частности, с помощью команды man 3 errno можно получить список кодов ошибок, определенных POSIX. Тем не менее, ситуация часто изменяется, и man-страницы не всегда отвечают существующему состоянию дел. Если системный вызов возвращает неожиданный код ошибки, можно предположить, что скорее man-страница устарела, а не системный вызов дал сбой. Исходный код Linux поддерживается более тщательно, чем документация.

Распространены и некоторые другие коды возврата ошибок, которые относятся только к сетевым функциям. Более подробную информацию можно найти в главе 17.