книги хакеры / журнал хакер / специальные выпуски / Специальный выпуск 51_Optimized

включает все виды оптимизаций, включающихся ключом "O2", которые не увеличивают размер выходного кода. Плюс еще кое-что. За более подробной информацией обращайся к info-страницам по GCC.

Для отладки написанной программы необходимо совершить еще одно телодвижение - добавить отладочную информацию к программе. Для этого при компиляции (с использованием GCC) необходимо добавить ключ "-g". Именно он и сделает то, что нам нужно. Вообще, отладочная информация может быть представлена в нескольких форматах. Один из них - формат, "разработанный" специально для использования с gdb. Для осуществления этого есть специальный ключ - "-ggdb".

Одной интересной особенностью компилятора GCC является тот факт, что ключи g и O<x> могут быть использованы одновременно. Так можно попросить компилятор оптимизировать код, а затем добавить отладоч- ную информацию. И в итоге получа- ешь результаты такой оптимизации в наглядном виде. Некоторые константы и переменные могут исчезнуть, блоки кода - изменить свое положение в программе. А некоторые - вообще не исполняться, так как их результат заранее можно просчитать и он никогда не меняется. Кстати, можно задать количество отладочной информации, помещаемой в результирующий файл. Всего существует три уровня, второй используется по умол- чанию. Задается все ключом "-g<x>" или "-ggdb<x>". Уровень один - минимум, уровень три - максимум (добавляется информация о макросах в программе). Такие вот дела.

НАЧИНАЕМ

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

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

Если твои программы соответствуют стандарту ANSI C или C99, то они будут легко компилироваться под любой ОС с использованием "правильного" компилятора. Однако стремление к соответствию упомянутым стандартам, к сожалению, не разбудит полностью все таланты системы.

Для любой *nix-программы, помимо стандартных заголовков stdlib.h & stdio.h, необходимо использование заголовка unistd.h. При использовании некоторых специфичных типов данных необходимо подключать заголовок sys/types.h.

Для примера рассмотрим основные функции (примитивы) для работы с файлами, предоставляемые любой *unix-системой. Эти функции состоят из небольшого набора системных вызовов, обеспечивающих непосредственный доступ к средствам ввода\вывода ОС. Одновременно с этим они являются основой для всей системы ввода\вывода *nix, и многие другие механизмы доступа к файлам (например) основаны именно на них.

Вот они: Open - открытие файла, Close - закрытие, Read - чтение данных, Write - запись данных, Lseek - перемещение в заданную позицию в файле, Fcntl - управление связанными с файлом атрибутами.

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

Системные вызовы ввода\вывода являются основой всей системы ввода\вывода *nix, но они примитивны и предоставляют возможность работы с данными в виде простой последовательности байт.

Читай man'ы и посещай (очень советую) www.tldp.org, содержащий огромное коли- чество самой разной увлекательной и познавательной информации по Linux.

интересны значения параметра cmd F_GETFL & F_SETFL. Они позволяют узнать\изменить текущие флаги статуса открытого файла. Вот как, например, можно узнать текущий статус файла (модификатор доступа):

int arg = fcntl(fd, F_GETFL); if (arg & O_APPEND)

printf("ôëàã O_APPEND");

if ((arg & O_ACCMODE) == O_RDWR) printf("файл открыт для чтения и записи")

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

При запуске новой программы ОС автоматически открывает три дескриптора файла, которые называются стандартным вводом, стандартным выводом и стандартным выводом диагностики соответственно. Они всегда имеют значения 0, 1 и 2. Не спутай stdin, stdout & stderr с чем-нибудь другим из стандартной билиотеки ввода\вывода.

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

Системные вызовы ввода\вывода являются основой всей системы ввода\вывода *nix, но они примитивны и предоставляют возможность работы с данными в виде простой последовательности байт, что не всегда может быть удобно для программиста, потому что заставляет его задумываться над многими вещами. Хочу напомнить тебе о стандартной библиотеке ввода\вывода, описанной в stdio.h и содержащей намного больше средств (fprintf, getc, putc, etc), нежели упомянутые системные вызовы.

В *nix с каждым процессом связана маска создания файла, которая используется для автоматического выключения заданных битов прав доступа при создании новых файлов. Это бывает полезно для защиты от случайного включения "ненужных" прав доступа. В терминах языка C, если счи- тать, что маска задана в целочисленной переменной Mask, то реальные права доступа будут получены следующим выражением: (~mask) & mode.

Для изменения маски создания файла существует системный вызов Umask, принимающий единственный параметр типа mode_t (который в оче- редной раз оказывается обычным це-

лым числом). Например, вызов umask(022) запрещает вновь созданным файлам текущего процесса присвоение файлу прав доступа на запись. Всем, кроме владельца.

Раз речь зашла о правах доступа, и теперь стоит упомянуть такой системный вызов, как Access, который определяет, может ли процесс полу- чить доступ к файлу в соответствии с истинным (а не с действующим) идентификатором пользователя и группы. И еще один системный вызов - Chmod. Здесь комментарии излишни.

В *nix один файл может иметь несколько имен. То есть существует возможность связать одну и ту же последовательность данных с несколькими именами, а создавать копии файла не нужно. Такое имя называется жесткой ссылкой, а количество таких ссылок, связанных с файлом, - счетчик ссылок. Для добавления нового имени используется системный вызов Link (const char *original, const char *link), а для удаления - Unlink (char *name), который просто удаляет указанное имя и уменьшает счетчик ссылок на единицу. Сами же данные будут безвозвратно потеряны только в том случае, если этот счетчик равен

нулю и если указанный файл не открыт для чтения ни в одной программе. Замечу, что для создания символьных ссылок используется системный вызов Symlink, описанный в unistd.h.

МНОГОЗАДАЧНОСТЬ

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

Основным примитивом, создающим процесс в *nix-системах, является системный вызов Fork() - фактически в нем и заключается вся многозадач- ность ОС. После успешного вызова этой функции ядро создаст новый, почти идентичный текущему процесс - дочерний. Оба процесса будут выполняться одновременно, продолжая свое выполнение с оператора, следующего за Fork(). Как различить эти два процесса? Если функция возвращает 0, значит, ты добрался до про- цесса-потомка. Если возвращаемое число > 0, то ты застрял на родительском. Иначе - системный вызов завершился с ошибкой, которую нужно анализировать.

Следующим системным вызовом, который необходимо упомянуть -

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

Кроме процессов существует еще один вид программной сущности - потоки. Что-то вроде облегченных процессов, выполняющихся в одном адресном пространстве. Примитивов работы с ними немало, и для каждой системы они свои. Однако любая POSIX-система включает в себя реализацию Posix-threads. Пару слов о ней: в ОС есть набор функций, описанных в pthread.h и называющихся pthread_*. Например, pthread_create() создает новый поток, возвращая его идентификатор. Конечно, одним из параметров этой функции будет указатель на функцию, которая станет новым потоком и начнет свое выполнение. Функция Pthread_cancel может попытаться завершить поток, а Pthread_exit будет являться аналогом обычного Exit для процесса.

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

Нет ничего страшного, если в каче- стве оболочки ты используешь sh. Возможно также, что у тебя установлен Korn Shell (ksh) или что-то еще, тогда тебе нужно всего лишь придерживаться стандарта POSIX, если хо- чешь, чтобы твои shell-сценарии могли быть интерпретированы другим шеллом. Пройдя по ссылке www.unix.org.ua/orelly/unix/ksh/appa_02.htm, ты сможешь прочитать статью о IEEE 1003.2 POSIX shell стандарте и его поддержке в Korn shell. Дополнительные же преимущества bash опишу чуть позже.

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

Обычно все сценарии начинаются с одной из следующих строк или набора строк:

#!/bin/sh

#!/bin/bash

#!/usr/bin/perl

#!/usr/bin/tcl #!/bin/sed -f #!/usr/awk -f

Ты, наверное, уже заметил, что каждая строка начинается одинаково, с символов "#!". Эти строки объясняют системе, что запущенный файл, - это не что иное, как сценарий, и его следует обработать с помощью указанного после символов "#!" интерпретатора.

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

ñhmod 700 my_script_name.sh

èëè

chmod u+rwx my_script_name.sh

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

sh my_script_name bash my_script_name

ОТ ТЕОРИИ К ПРАКТИКЕ

Я думаю, наступил момент рассмотреть какой-нибудь пример практического использования скрипта, из которого сразу все станет ясно. Но перед этим хочу обратить твое внимание на то, что некоторую полезную роль в написании кода играют редакторы. Современные редакторы имеют уйму разных функций от подсветки кода до вставки в текст некоторых несложных конструкций. Все это на любителя. Ты можешь использовать vi или emacs, а мне хватает встроенного в Midnight comander редактора с подсветкой синтаксиса. Ну а выбор, как всегда, за тобой. Определись, что тебе больше нравится, и забудь.

Чтобы далеко за примерами не ходить, я решил залогиниться на свой ALT Master 2.2 и взять первый попавшийся на глаза скрипт запуска одного из демонов. Такие скрипты, как известно, находятся в /etc/rc.d/init.d/. Первым в каталоге init.d оказался файл Anacron - сценарий запуска для одного очень популярного планировщика задач, похожего на всем известный демон cron. Anacron также может периодически запускать команды в назначенное время, и в отличие от cron, нет необходимости постоянной работы системы (но это уже совсем другая история).

Разберем файл построчно. Как мы видим, в начале файла используется до боли знакомая конструкция, начи- нающаяся с "#!". Ты уже знаешь, на что она указывает системе. Далее следуют комментарии, которые предваряются символом "#". А вот тут уже становится интересно: появилась ка- кая-то строка, да еще с точкой в нача- ле. Вот она:

. /etc/init.d/functions

На самом деле ничего странного здесь нет. Символ "." является экви-

валентом команды source. Внутри сценария команда source other_file_name подключает файл other_file_name.

Она очень напоминает директиву препроцессора языка C/C++ - "#include". Коротко пробегись по включенному файлу и получи представление о том, что же представляет собой скрипт functions. На самом деле все становится предельно ясно с комментариями к файлу. Этот сценарий содержит функции, наиболее часто используемые скриптами автозапуска из /etc/init.d. Дальше в файле как раз встречаются функции, которые очень часто можно найти в скриптах.

Но вернемся к нашему сценарию автозапуска anacron.

[ -f /usr/sbin/anacron ] || exit

В данной строке мы видим опять же эквивалент команды Test. Как понятно из названия, она проверяет условие, которое в этом случае заключено в квадратные скобки. Ключ -f задается для проверки существования файла. Таким образом, данный блок операторов служит для того, чтобы точно знать, существует ли файл демона /usr/sbin/anacron, и только в этом слу- чае продолжать выполнение скрипта,

àиначе выйти вон.

Далее следует инициализация пере-

менных LOCKFILE и RETVAL, которая происходит при присвоении им определенных значений. Пока для нас эти переменные ничего не значат. При программировании на shell переменные не имеют типа, но в зависимости от того, какое значение им присвоено, возможна, например, целочисленная арифметика с переменными. После того как переменной присвоено зна- чение, ее можно использовать в каче- стве подстановки, приписав в начале ее имени символ "$". И помни разницу между именем переменной (RETVAL) и ее значением ($RETVAL): если, например, посмотреть в самый конец рассматриваемого скрипта, обнаружишь строку exit $RETVAL. Здесь используется оператор exit для завершения программы, который тоже возвращает значение переменной RETVAL.

83

Ну вот мы и добрались до начинки файла - объявления функций start(), stop() и restart(). Под их контроль как раз и попадает обработка параметров, поступающих скрипту от пользователя или других программ. Как понятно из названий, каждая функция производит соответственно запуск, останов или restart демона. В принципе, здесь все понятно. Интересно то, что дальше в функциях встречаются не совсем логичные переменные $?, $$, $PPID. Ничего подобного не объявлялось, тогда откуда они взялись? Сейчас все станет ясно. Дело в том, что существует специальный тип переменных - так называемые переменные окружения. В рамках любого процесса есть некоторое окружение, то есть набор переменных, к которым он может обращаться за получением определенных данных. Каждый раз, когда запускается командный интерпретатор, для него создаются переменные окружения. Эти переменные можно экспортировать любому дочернему процессу с помощью команды Export. Список переменных можно получить командой Set. Количество переменных окружения достаточно велико, поэтому в командной строке лучше дать команду set|more для того, чтобы иметь возможность пролистать весь список.

Так вот, переменная $? содержит значение последней выполнившейся команды. А переменная $$ таит в себе не что иное, как PID сценария, то есть идентификатор процесса сценария. Переменная $PPID - PPID, то есть родительский идентификатор процесса.

Получается вот что (сразу не скажу, что): внимательно посмотри на функцию Start().

daemon anacron -s

Командой Daemon пытаемся запустить файл демона anacron с опцией -s для синхронизации заданий. При удачном запуске команда Daemon вернет значение "0".

Уже известно, что переменная $? будет содержать код возврата пос- »

Скачать tar.gz архив с исходниками bash любой версии, а также прочи- тать более подробную информацию ты можешь с сайта GNU Project www.gnu.org/s oftware/bash/b ash.html

Нужно учитывать, что строка #!/bin/sh на самом деле означает интерпретатор, использующийся в системе по умолчанию, которым в большинстве дистрибутивов Linux является bash.

При работе со строками в bash можно воспользоваться неинтерактивным строчным редактором sed и языком обработки шаблонов awk.

Определить версию bash, установленную у тебя, можно с помощью параметра --ver- sion.

объявления функции start(). Теперь запустим его следующим образом:

bash -x anacron

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

ДОПОЛНИТЕЛЬНЫЕ ВОЗМОЖНОСТИ BASH

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

ние проекта. Имея независимые версии для Windows и *nix, ты вынужден вносить исправления и гонять баги в обеих программах одновременно.

Портабельный код этих недостатков лишен. Якобы. Скажи, когда-нибудь ты пробовал писать программу, компилируемую более чем одним компилятором? Ругался при этом? И правильно! Я бы тоже ругался. Ограниче- ния, налагаемые переносимым кодом, лишают нас многих возможностей языка и значительно увеличивают трудоемкость разработки. Допустим, ты используешь шаблоны (Templates), и на MS VC все работает, но при переходе на другой компилятор программа разваливается к черту. А некоторые компиляторы не инициализируют статические экземпляры класса. Ну не инициализируют и все тут! Забудь о стандартах. Компиляторы все равно их не придерживаются.

При каждом внесении изменений в программу прогоняй ее через все целевые компиляторы. Код, специфичный для данной платформы, заботливо окружи #ifdef или вынеси в отельный файл, ну и т.д. В конечном счете ты получишь все те же два независимых проекта, но тесно переплетенные друг с другом, причем внесение изменений в один из них дает непредсказуемый эффект в другом. Нет-нет, не подумай! Я вовсе не противник переносимого кода, просто не понимаю тех, для кого переносимость является целью, а не средством. Никто не спорит, что такие проекты, как Apache или GCC, должны изначально разрабатываться как переносимые (процент системно-независимого кода в них очень велик), но вот мелкую утварь типа почтового клиента лучше зата- чивать под индивидуальную плат-

форму, а при переходе на *nix переписывать заново.

СЛОИ АБСТРАГИРОВАНИЯ

Если нужно быстро перенести программу - воспользуйся WINE или Willows. Это бесплатно распространяемые имитаторы Windows, оборачивающие *nix-функции толстым слоем переходного кода, реализующего Win32 API и работающие на: Windows 9x/NT/2000/XP, Linux, FreeBSD, Solaris, а Willows еще и на QNX.

Обрати внимание: не эмуляторы, а именно имитаторы (WINE именно так и расшифровывается: Wine Is Not Emulator - это вам не эмулятор). Портируемая программа исполняется на "живом" процессоре практически без потерь в скорости. Во всяком случае реклама говорит именно так. А что реальная жизнь? При всей схожести *nix и Windows NT (их ядра наследуют общий набор концепций) они во многом различаются. В *nix есть замеча- тельная функция Fork, расщепляющая процесс напополам. В NT ее нет. Функциям CreateProcess/CreateThread далеко до Fork. И вот почему. Накладные расходы на расщепление процесса ничтожны, чего нельзя сказать о создании процесса/потока с нуля. Кстати, с потоками в Linux сплошной напряг; внутренние потоки представляют те же процессы, но только немного усложненные. Всегда заменяй CreateThread на Fork, когда это только возможно (процессы, в отличие от потоков, исполняются в различных адресных пространствах и могут обмениваться данными только че- рез IPC, например, так происходит с проецированными в память файлами). К тому же средства синхронизации потоков в Windows и *nix далеко не как две капли воды, а в Linux-син-

хронизация не поддерживается вовсе

èреализуется внешними библиотеками. Все это делает отображение Win32 API на *nix-функции неоднозначным,

èвыбор предпочтительного системного вызова в каждом конкретном слу- чае должен определяется индивидуально. Человеком. Имитатор на это не способен, и падения производительности не избежать (другое дело, что при современных аппаратных мощ-

ностях о производительности можно не вспоминать).

Конструктивно большинство имитаторов состоят из двух основных компонентов: бинарного интерфейса (Binary Interface) и библиотеки разработчика (Library). Некоторые имитаторы (например, Willows) включают еще и уровень абстрагирования от платформы (Platform-abstraction Layer), что упрощает их перенос на

87

другие системы, но это уже детали реализации.

Бинарный интерфейс включает в себя win32-загрузчик, "переваривающий" PE-файлы и с максимальной точностью воссоздающий привычное для них окружение. Необходимость в перекомпиляции при этом отпадает, однако совместимость остается на очень низком уровне. Реально удается запустить лишь небольшое коли- чество офисных приложений типа Office, Acrobat или Photoshop. Системные утилиты, скорее всего, откажутся работать, и тут на помощь приходит библиотека - заголовочные файлы плюс lib-файл. Адаптировав приложение, можно компилировать его как в ELF (тогда необходимость иметь на машине установленный имитатор отпадает) или в PE. Красота!

В крайнем случае можно воспользоваться полноценным эмулятором PC - VMWare или Win4Lin, однако полезность этого решения сомнительна. Дело даже не в аппаратных требованиях (я вполне успешно гоняю VMWare на P-III 733), а в удобстве использования (точнее, его отсутствии). Достаточно сказать, что обмениваться данными с эмулятором придется через виртуальную локальную сеть, гоняя их в обе стороны, в хвост и в гриву.

ПЕРЕНОС ПРИЛОЖЕНИЙ, СОЗДАННЫХ В MICROSOFT VISUAL STUDIO

Компания Mainsoft (та самая, у которой свистнули исходные тексты Windows 2000) выпустила замеча- тельный продукт Visual MainWin, позволяющий писать код в Microsoft Visual Studio и тут же компилировать его под разные платформы (Windows, Linux, HP-UP, AXI, Solaris), причем количество поддерживаемых платформ постоянно растет.

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