Процесс компиляции программ на языке C (Семинары), страница 2

Транслятор выполнит:

. Проверку отсутствия синтаксических ошибок

. Компилятор C++ также выполняет раскрытие шаблонов

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

. Если нет фатальных ошибок, преобразует операторы C в команды ассемблера.

Опции транслятора

Современные трансляторы C/C++ имеют большое количество опций, управляющих выдачей предупреждений, используемыми оптимизациями, поддержкой разных диалектов языка, включением инструментации для профилирования, поиска утечек памяти и др.. В зависимости от комплекта поставки, компилятор может включать поддержку нескольких аппаратных архитектур. Так, SunStudio для x86 может генерировать код как для 32-разрядной архитектуры x86, так и для 64-разрядной x64, а также проводить оптимизации под разные модели процессоров соответствующих архитектур. Эти опции различаются у разных трансляторов и перечислены в руководствах по соответствующим компиляторам.

Стандартные опции, поддерживаемые всеми современными компиляторами для Unix, включают в себя:

-g Генерирует таблицу символов для отладки с помощью символьного отладчика dbx(1). Эта опция также передается ассемблеру и редактору связей.

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

-S Не вызывает ассемблер. Оставляет результат в файле с расширением .s. Этот файл будет содержать команды языка ассемблера, "родного" для целевого компьютера.

-fPIC Генерирует позиционно-независимый код для использования в разделяемых библиотеках

Процесс Си-компиляции - Фаза ассемблера

Фаза ассемблера конвертирует исходные тексты на языке ассемблера в объектный код.

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

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

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

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

Процесс компиляции — Редактор связей

Финальной стадией процесса компиляции является редактор связей или линкер.

Редактор связей создает исполняемый файл, объединяя объектные файлы, выполняя перемещение кода и разрешая внешние ссылки. Например, если один из объектных файлов содержит вызов функции printf(3C), редактор связей будет искать эту функцию по всем объектным файлам и библиотекам и выдаст ошибку сборки, если не найдет.

Объектный код, используемый для создания исполняемой программы, находится в объектных файлах, а также разделяемых и архивных библиотеках. По умолчанию, кроме пользовательских объектных файлов и библиотек, в состав программы включается файл /usr/lib/crt1.o. Этот файл содержит адрес точки входа программы и код, инициализирующий среду исполнения языка C. При сборке программы для исполнения в нестандартном окружении, например, в качестве ядра ОС, может быть необходимо задать другой стартовый файл при помощи соответствующих опций редактора связей.

Стандартная библиотека языка C /lib/libc.so просматривается без явного запроса пользователя. Редактору связей можно задать просмотр других библиотек, кроме libc.so, или отключить просмотр этой библиотеки. Например, при сборке ядра ОС, не следует подключать стандартную библиотеку языка C, потому что её функции содержат системные вызовы, а ядро не может выполнять системные вызовы, во всяком случае, теми же средствами, какими это делает libc.

Архивные библиотечные файлы имеют расширение .a и создаются командой ar(1). По существу, такие файлы представляют собой просто коллекции объектных модулей. При подключении архивной библиотеки, из неё извлекаются только те модули, в которых определены переменные и функции, используемые вашей программой. Эти модули включаются в состав исполняемого файла вашей программы, поэтому сборка с архивной библиотекой называется также статической сборкой.

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

Файлы разделяемых библиотек имеют расширение .so (shared object). При сборке с такими библиотеками, редактор связей определяет, в какой именно библиотеке находится требуемая функция, и генерирует таблицу PLT (Procedure Linkage Table), включаемую в состав вашей программы. Таблица PLT содержит информацию, что функцию printf надо искать в библиотеке libc.so. При этом, сама библиотека в состав вашей программы не включается, а присоединяется к вашей программе при её запуске. Связь между функцией printf и её кодом в libc.so устанавливается только при первом вызове этой функции. Такая сборка называется динамической сборкой.

Разделяемые библиотеки формата ELF допускают также настоящую динамическую сборку, когда библиотека не подключается редактором связей, а открывается во время исполнения функцией dlopen(3С). Затем, программа может найти адрес нужной ей функции по имени функцией dlsym(3C) и вызывать эту функцию по адресу (в языке C адрес функции называется «указатель на функцию»).

Если при работе редактора связей не случилось ошибок, результат помещается в файл a.out.

Некоторые опции редактора связей

Ниже показаны наиболее часто употребляемые опции редактора связей:

-lname Определяют способ сокращенного задания имени архивного или разделяемого библиотечного файла. Он обозначает подключение библиотеки libname.so или libname.a в зависимости от параметров ключей -d и -B. По умолчанию, директории /lib и /usr/lib просматриваются при поиске библиотеки x.

-d y|n Определяет статическую или динамическую сборку. Параметр y, действующий по умолчанию, указывает динамическую сборку. При этом редактор связей сначала пытается подключить разделяемую версию библиотеки (файл .so), а если она не будет найдена, то архивную версию. При параметре n используется статическая сборка и редактор связей ищет только архивные библиотеки.

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

-B static|dynamic Позволяет переключать статический или динамический режим сборки для отдельных библиотек. Может указываться в командной строке несколько раз и действует на все следующие опции -l до конца строки или следующей опции -B.

-Ldir Добавляет директорию dir в начало списка директорий, в которых следует искать библиотеки, задаваемые опцией -l, перед /lib и /usr/lib. Дополнительные директории для поиска библиотек можно также задавать переменной среды LD_LIBRARY_PATH.

-oname Определяет имя name для результирующего исполняемого файла. Имя по умолчанию - a.out.

-s Удаляет отладочную информацию: номера строк исходного кода и информацию, содержащуюся в таблице символов, что позволяет уменьшить размер исполняемого файла, но затрудняет использование dbx(1).

-g Включает отладочную информацию в исполняемый файл, что позволяет использовать символьные отладчики. Отладочную информацию можно удалить из собранного исполняемого файла командой strip(1).

-G Генерация разделяемой библиотеки (файла с расширением .so). Несовместима с ключом -dn. При генерации разделяемой библиотеки, объектные модули могут содержать неразрешенные ссылки и доступен ряд других опций, управляющих тем, какие из определенных в ваших объектных модулях символы должны быть включены в список экспорта библиотеки. Желательно, чтобы все модули, включаемые в библиотеку, были оттранслированы с ключом -fPIC. Процедура сборки разделяемых библиотек подробнее описана в странице системного руководства ld(1) и в документе «Linker and libraries guide» на сайте http://docs.oracle.com.

Пpимеpы

Примеры: Три исходных файла компилируются и исполняемый файл переименовывается в prog:

cc prog.c f.c g.c -o prog

Компоновка объектного файла из заранее скомпилированых файлов .o и функций из /lib/libPW.a:

cc -om m.c f1.o -lPW

Просмотр текущей и HOME директории для поиска архивного файла libxyz.a:

cc p.c -L. -L$HOME -lxyz -o p

Утилита make

При разработке и отладке программ, состоящих из большого числа исходных модулей, возникает желание оптимизировать процесс компиляции, перекомпилируя только те файлы, которые изменялись с момента предыдущей компиляции. Для этого предназначена утилита make(1). Для Solaris доступны три версии make: традиционная версия утилиты Unix System V, GNU Make и распределенная версия make (dmake), входящая в поставку пакета SunStudio. Далее будут рассматриваться возможности, общие для всех версий этой утилиты.

make определяет правила, по которым надлежит компилировать файлы, на основе специального текстового файла. Если запустить make без параметров, она пытается взять эти правила из файла Makefile в текущей директории. Если правила размещены в файле с другим именем, то make следует запускать с опцией -f, например make -f my-makefile. Далее в этом разделе мы будем называть входной файл Makefile.

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

target: dependencies command

При этом, target представляет собой имя целевого файла, например, исполняемого или объектного. Dependencies представляет собой список разделенных пробелами имен файлов, от которых целевой файл зависит. Для типичного программного модуля на языке C, целевым файлом будет объектный модуль (.o-файл), а файлами зависимостей — исходный файл на языке C и заголовочные файлы, которые этот файл включает директивой #include. Не следует включать в список зависимостей системные заголовочные файлы, нужно включать только файлы вашего программного проекта, которые могут быть изменены в ходе разработки.

Command — это команда shell, которую нужно исполнить для «делания» файла, то есть для получения целевого файла из файлов зависимостей. Русскоязычные программисты обычно называют «делание» сборкой. Для файлов на языке C сборка, скорее всего, заключается в компиляции с ключом -с, однако в реальных проектах возможны и более сложные ситуации. Например, если ваша программа использует автоматически генерируемый при помощи утилиты yacc(1) синтаксический анализатор, ее Makefile может включать правило для генерации текста на языке C при помощи yacc(1) из файла на входном языке yacc.

Перед началом command должно быть один или несколько пробелов или табуляций. Команда может состоять из нескольких строк, каждая из которых исполняется как отдельная команда shell. При успешном завершении сборки, последняя команда должна возвращать код 0.

Примеры правил и Makefile

Для .o-файла, получаемого из .c-файла, правило может выглядеть так:

main.o: main.c functions.h сс -c main.c

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

hello: main.o factorial.o hello.o cc main.o factorial.o hello.o -o hello

Весь Makefile в целом может выглядеть так:

hello: main.o factorial.o hello.o cc main.o factorial.o hello.o -o hello main.o: main.c functions.h cc -c main.c factorial.o: factorial.c functions.h cc -c factorial.c hello.o: hello.c functions.h cc -c hello.c clean: rm -rf *o hello

При сборке с таким файлом, утилита make работает следующим образом: если в командной строке указан параметр с именем цели, например, make clean, утилита пытается собрать указанную цель, в данном случае цель clean. Если цель в командной строке не указана, make пытается собрать первую цель в файле, в данном случае hello.

При сборке каждой цели, make сравнивает дату модификации целевого файла с датами модификации файлов зависимостей. Если целевой файл имеет дату модификации позже, чем файлы зависимостей, считается, что ничего делать не надо. Если же целевого файла нет или какой-то из файлов зависимостей был модифицирован позже целевого файла, соответствующий целевой файл собирается. Если какого-то из файлов зависимостей нет и нет правила, как его сделать, make выдает ошибку. Например, если в текущей директории нет файла functions.h, make выдаст ошибку "Don't know how to make functions.h".