Что такое двоичный интерфейс приложения (ABI)?

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

Если вы знаете сборку и как вещи работают на уровне ОС, вы соответствуете определенному ABI. Аби управляют вещами, такими как параметры передаются, где размещены значения возврата. Для многих платформ есть только одна аби на выбор, а в этих случаях ABI - это просто «Как вещи работают».

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

Кроме того, если у вас есть 64-битная OS, которая может выполнять 32-битные двоичные файлы, у вас будет разные ABIS для 32- и 64-битного кода.

В целом любой код, который вы ссылаетесь, на тот же исполняемый файл, должен соответствовать тому же ABI. Если вы хотите общаться между кодом, используя разные abis, вы должны использовать некоторую форму протоколов RPC или сериализации.

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

Абис может быть (частично) ISA-agnostic. Некоторые аспекты (такие как соглашения о вызовах) зависят от ISA, в то время как другие аспекты (такие как класс класса C ++).

Хорошо определенный ABI очень важен для людей, пишущих компиляторы. Без четко определенного ABI было бы невозможно сгенерировать совместимый код.

Править: Некоторые заметки для уточнения:

• «Двоичный» в ABI не исключает использование строк или текста. Если вы хотите связать DLL экспортирую класс C ++, где-то в нем методы и подписи типа должны быть закодированы. Вот где приходит на имя C ++.
• Причина, по которой вы никогда не предоставили ABI, так это то, что подавляющее большинство программистов никогда не сделает этого. Abis предоставляются теми же людьми, разработающими платформу (I.E. Операционная система), и очень немногие программисты когда-либо будут иметь привилегию для разработки широко используемых ABI.

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

Системный вызов - это способ для программы, работающей в пользовательском пространстве, запросить что-нибудь в ядре. Она работает, помещая числовой код вызова и аргумент в определенный регистр и вызывая прерывание. Затем происходит переключение в пространство ядра и ядро ищет цифровой код и аргумент, обрабатывает запрос, помещает результат обратно в регистр и запускает переключение обратно в пользовательское пространство. Это необходимо, например, когда приложение хочет выделить память или открыть файл (syscalls "brk" и "open").

Теперь у системных систем есть короткие имена "brk" и т.д. и соответствующие опкоды, они определяются в системном специфическом заголовочном файле. До тех пор, пока эти опкоды остаются неизменными, вы можете запускать одни и те же скомпилированные программы пользовательского интерфейса с разными обновленными ядрами без необходимости перекомпиляции. Итак, у вас есть интерфейс, используемый прекомпилированными бинарчиками, отсюда и ABI.

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

Прежде чем мы продолжим, убедитесь, что поведение, продемонстрированное ниже, является тем, чего вы ожидаете от Python.

>>> a1 = [1]
>>> a2 = a1
>>> print a2[0]
1
>>> a1[0] = 2
>>> print a2[0]
2

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

>>> a1 = (1,)
>>> a2 = a1
>>> print a2[0]
1
>>> a1 = (2,)
>>> print a2[0]
1

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

Почему это важно? Допустим, у вас есть дикт:

>>> t1 = (1,2)
>>> d1 = { t1 : 'three' }
>>> print d1
{(1,2): 'three'}
>>> t1[0] = 0  ## results in a TypeError, as tuples cannot be modified
>>> t1 = (2,3) ## creates a new tuple, does not modify the old one
>>> print d1   ## as seen here, the dict is still intact
{(1,2): 'three'}

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

К сожалению, увеличение:: поток не является библиотекой «только для заголовка», поэтому его необходимо скомпилировать. Есть два способа обойти его.

1. Предварительно созданный установочный пакет загружается из boostpro (при условии, что вы находитесь в окнах) -- https://sourceforge.net/projects/boost/files/boost-binaries/
2. вы можете построить его самостоятельно - см. http://www.boost.org/doc/libs/1_35_0/more/getting_started/index.html

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

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

Функциональность: набор контрактов, влияющих на компилятор, средства записи сборки, компоновщик и операционную систему. Контракты определяют, как функции выложены, где передаются параметры, как передаются параметры, как работают возвращаемые функции. Обычно они относятся к кортежу (архитектура процессора, операционная система).

Существующие объекты: структура параметров, семантика функций, размещение регистров. Например, архитектуры ARM имеют множество ABI (APCS, EABI, GNU-EABI, не говоря уже о множестве исторических случаев) - использование смешанного ABI приведет к тому, что ваш код просто не будет работать при вызове через границы.

Потребитель: компилятор, средства записи сборки, операционная система, архитектура процессора.

Кому нужны эти подробности? Компилятор, средства записи сборки, компоновщики, выполняющие генерацию кода (или требования к выравниванию), операционная система (обработка прерываний, интерфейс системных вызовов). Если вы занимались программированием на ассемблере, вы соответствовали ABI!

Изменение имени C ++ - это особый случай - это проблема, связанная с компоновщиком и динамическим компоновщиком. Если изменение имени не стандартизировано, то динамическое связывание не будет работать. Отныне C ++ ABI называется просто C ++ ABI. Это не проблема уровня компоновщика, а проблема генерации кода. Если у вас есть двоичный файл C ++, невозможно сделать его совместимым с другим ABI C ++ (изменение имени, обработка исключений) без перекомпиляции из исходного кода.

ELF - это формат файла для использования загрузчика и динамического компоновщика. ELF - это формат контейнера для двоичного кода и данных, и как таковой определяет ABI фрагмента кода.Я бы не стал рассматривать ELF как ABI в строгом смысле слова, поскольку исполняемые файлы PE не являются ABI.

Все ABI зависят от набора команд. ARM ABI не имеет смысла на процессорах MSP430 или x86_64.

В Windows есть несколько ABI - например, fastcall и stdcall являются двумя часто используемыми ABI. Системный вызов ABI снова отличается.

Бинарный интерфейс приложения (ABI) похож на API, но функция недоступна для вызывающей стороны на уровне исходного кода. Доступно / доступно только двоичное представление.

ABI могут быть определены на уровне архитектуры процессора или на уровне ОС. ABI - это стандарты, которым должна следовать фаза генератора кода компилятора. Стандарт устанавливается либо ОС, либо процессором.

Функциональность: Определите механизм / стандарт для выполнения вызовов функций независимо от языка реализации или конкретного компилятора / компоновщика / инструментальной цепочки. Обеспечить механизм, который позволяет использовать JNI или интерфейс Python-C и т. Д.

Существующие объекты: функции в форме машинного кода.

Потребитель: Другая функция (в том числе функция на другом языке, скомпилированная другим компилятором или связанная другим компоновщиком).