Запуск приложения

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

При записи приложения Mac необходимо использовать платформу Launch Services для запуска других приложений. Launch Services понимает пакеты приложений, и можно использовать ее для открытия и приложений и документов. Средство поиска и Прикрепление используют Launch Services для поддержания базы данных отображений от типов документов до приложений, которые могут открыть их. Приложения какао могут использовать класс NSWorkspace запустить приложения и документы; NSWorkspace самостоятельно использование Launch Services. Launch Services в конечном счете вызывает fork и execve выполнять фактическую работу создания и выполнения нового процесса. Для получения дополнительной информации о Launch Services см. Руководство по программированию Launch Services.

Разветвление и выполнение процесса

Для создания процесса с помощью системных вызовов BSD процесс должен вызвать fork системный вызов. fork вызов создает логическую копию Вашего процесса, затем возвращает ID нового процесса к Вашему процессу. И исходный процесс и новый процесс продолжают выполняться от вызова до fork; единственная разница - это fork возвращает ID нового процесса к исходному процессу и нуля к новому процессу. ( fork функциональные возвраты -1 к исходному процессу и наборам errno к определенному ошибочному значению, если не мог бы быть создан новый процесс.)

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

Мужественный исполняемый файл содержит заголовок, состоящий из ряда команд загрузки. Для программ, пользующихся совместно используемыми библиотеками или платформами, одна из этих команд указывает расположение компоновщика, чтобы использоваться для загрузки программы. При использовании XCode это всегда /usr/lib/dyld, стандартный OS X динамический компоновщик.

Когда Вы вызываете execve подпрограмма, ядро сначала загружает указанный программный файл и исследует mach_header структура в начале файла. Ядро проверяет, что файл, кажется, допустимый Мужественный файл, и интерпретирует команды загрузки, сохраненные в заголовке. Ядро тогда загружает динамического компоновщика, указанного командами загрузки в память, и выполняет динамического компоновщика на программном файле.

Динамический компоновщик загружает все совместно используемые библиотеки, которые основная программа соединяет против (зависимые библиотеки) и обязывает достаточно символов запускать программу. Это тогда вызывает функцию точки входа. Во время изготовления статический компоновщик добавляет стандартную функцию точки входа к основному исполняемому файлу от объектного файла /usr/lib/crt1.o. Эта функция устанавливает состояние среды выполнения для ядра и вызывает статические инициализаторы для объектов C++, инициализирует время выполнения Objective C, и затем вызывает программу main функция.

Нахождение импортированных символов

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

ld -o my_tool -flat_namespace -undefined suppress peace.o love.o

Объем и обработка определений символа

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

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

int x = 0;

double y = 99 __attribute__((visibility("default")));   // GCC 4.0 only

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

extern int x;

extern void SomeFunction(void);

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

Стандарт C компилятор генерирует обычный символ, когда это видит предварительное определение — глобальная переменная, не имеющая никакого инициализатора и не отмеченная extern. Следующая строка является примером предварительного определения:

int x;

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

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

static int x;

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

Можно отметить символ как частный внешний при помощи __private_extern__ ключевое слово (который работает только в C), или visibility("hidden") атрибут (который работает и в C и в C++ с GCC 4.0), как в этом примере:

__private_extern__ int x = 0;                       // C only

int y = 99 __attribute__((visibility("hidden")));   // C and C++, GCC 4.0 only

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

Слабая ссылка является неопределенным внешним символом, который, как должны находить, для клиентской программы успешно не соединяется. Если символ не существует, динамический компоновщик обнуляет адрес символа. Файлы со слабыми ссылками могут использоваться только в OS X v10.2 и позже. Следующий код C демонстрирует conditionalizing вызов API с помощью слабой ссылки:

/* Only call this API if it exists */

if ( SomeNewFunction != NULL )

        SomeNewFunction();

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

void SomeNewFunction(void) __attribute__((weak_import));

Объединенная слабая ссылка является неопределенной внешней ссылкой на символ, определенный в многократных объектных файлах. В OS X v10.4 и позже (с GCC 4.0 и позже), можно указать, что символ превращен в объединенную слабую ссылку путем добавления слабого атрибута к объявлению символа. Например:

void SomeNewFunction(void) __attribute__((weak));

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

Отладочный символ является символом, сгенерированным компилятором, позволяющим отладчику отображаться от адресов в машинном коде к расположениям в исходном коде. Стандартные компиляторы генерируют отладочную информацию с помощью или формата Ударов или формата DWARF (поддерживаемый в Xcode 2.4 и позже). При использовании формата Ударов отладочная информация, как другие символы, сохранена в таблице символов (см. OS X ABI Мужественная Ссылка Формата файла). Но с форматом DWARF, отладочная информация сохранена в специализированном сегменте: __DWARF сегмент. С DWARF у Вас также есть опция хранения отладочной информации в отдельном файле отладочной информации, сокращающем размер двоичных файлов при разрешении полного опыта отладки, когда соответствующие файлы отладочной информации доступны.