Читать онлайн «Разработка приложений в среде Linux. Второе издание». Страница 19

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

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

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

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

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

Статические библиотеки представляют собой простые коллекции объектных файлов, объединенных утилитой ar (архиватор), ar группирует объектные файлы в один архив и добавляет таблицу, в которой указано, какие объектные файлы в архиве какие символы определяют. Затем компоновщик, ld, связывает ссылки на символ в одном объектном файле с определением этого символа в объектном файле архива. Для статических библиотек используется суффикс .а.

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

ar res libname.a foo.o bar.о baz.o

Также в архив можно добавлять объектные файлы по одному.

ar res libname.a foo.o

ar res libname.a bar.о

ar res libname.a baz.o

В любом случае libname.a получится одинаковым. В команде использованы перечисленные ниже опции.

r Включает объектные файлы в библиотеку, заменяя любой уже существующий в архиве файл с таким же именем. с Молча создает библиотеку, если таковой еще не существует. s Поддерживает в таблице соответствие названий символов объектным файлам.

При сборке статических библиотек необходимость в использовании других опций возникает не часто. Однако ar поддерживает другие опции и возможности, о которых подробно можно прочесть на man-странице команды.

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

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

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

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

• При обнаружении ошибки совместно используемую библиотеку можно заменить исправленной версией, а не компилировать повторно каждую программу, ее использующую.

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

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

Теперь стандартный формат двоичного файла практически на каждой платформе Linux представляет собой современный, расширяемый файловый формат ELF (Executable and Linking Format — формат исполняемых и компонуемых модулей), описанный в [24], ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.g и ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz. Это значит, что практически на всех платформах Linux шаги, предпринимаемые для создания и использования разделяемых библиотек, совершенно одинаковы.

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

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

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

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