Лекции по "Криптология "

 Многие из  перечисленных ОС, например MS Windows 3.x и Windows95, используют DOS и во время работы в качестве дисковой подсистемы. Тем не менее, эти системы умеют самостоятельно загружать пользовательские программы и выполнять все перечисленные во введении функции и должны, в соответствии с нашим определением, считаться полноценными операционными системами.

  Пример: Загрузка системы MS-DOS.

Выполнение начинается с фиксированного адреса (0FFFF0H), который  содержит команду передачи управления программе проверки системы и  программе начального загрузчика.

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

Дисковый начальный  загрузчик считывает первый сектор корневого каталога в поисках  файлов IO.SYS и MSDOS.SYS. Если нет таковых - "Non system disk or disk error". Если найден, то загружается файл IO.SYS, содержащий BIOS и модуль инициализации системы SYSINIT.

SYSINIT переносит  в память ядро системы (MSDOS.SYS) и вызывает находящуюся в ядре  программу инициализации.

Программа инициализации  ядра строит внутренние системные таблицы  и инициализирует резидентные драйверы, в результате чего становится доступен обычный дисковый сервис MS-DOS.

SYSINIT открывает  и выполняет файл CONFIG.SYS (если таковой  имеется) в результате чего  осуществляется настройка среды  - дополнит. драйверы, буферы, и т.п.

SYSINIT вызывает  системную функцию EXEC для выполнения COMMAND.COM (или другой оболочки).

Секция инициализации COMMAND.COM выполняет AUTOEXEC.BAT.

Выдается приглашение. Система готова к работе.

Сборка  программ

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

  Объектный модуль

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

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

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

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

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

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

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

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

Как правило, эта  информация разбита на именованные  секции. В masm/tasm такие секции называются сегментами, в DEC'овских и UNIX'овых ассемблерах - программными секциями (psect). В готовой программе весь код или данные, принадлежащие к одной секции, собираются вместе.

  Библиотеки объектных модулей

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

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

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

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

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

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

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

Варианты  построения загрузчиков

 Как следует  из вышеизложенного, подготовка программы к выполнению сопряжена со следующими взаимосвязанными процессами:

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

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

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

Как уже говорилось ранее, связывание (сборка) выполняется  специальной программой связывания, называемой также линкером или редактором связей.

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

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

 Загрузчики, обеспечивающие перемещение программ  называются перемещающими или  относительными загрузчиками (relocating/relative loaders).

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

 Основное  отличие между редактором связей  и связывающим загрузчиком иллюстрирует  рис.3.1.

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

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

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