Компоновщики и архитектура
Нет, но вы можете открыть веб-сервер, например, по адресу 127.0.0.77 и использовать его, чтобы проверить, является ли URI запроса "/welcome.aspx" ... Если да, перенаправить в Google, если не загружать оригинал сайт.
127.0.0.77 mysite.com
5 ответов
Есть много, много причин, и я не могу перечислить их все исчерпывающе.
Линкерам нужно делать очень много. больше работы, когда архитектура не поддерживает позиционно-независимый код. В таких случаях необходимо разрешить даже переходы внутри функций.
Компоновщикам необходимо создавать специфичные для архитектуры заголовки, такие как заголовки ELF или PE.
Линкерам необходимо включать ресурсы, ответвления данных или подобные вещи на поддерживающих их платформах.
Линкерам необходимо создавать экземпляры экспортированных шаблонов C ++.
Линкерам также необходимо иметь дело с адресами, которые еще не могут быть разрешены. Это может включать системные вызовы или динамически загружаемые библиотеки.
При компоновке динамической библиотеки компоновщик должен экспортировать более одной функции записи. В разных архитектурах используются разные методы для указания, какие функции должны быть экспортированы
Компоновщикам может потребоваться вставить фактические последовательности вызовов, если они не могут быть определены во время компиляции. Например, для архитектур, которые поддерживают два набора инструкций, «переключатель набора инструкций» должен быть вставлен всякий раз, когда вызывающий и вызываемый отличаются используемым набором инструкций.
Оптимизация компоновщика может быть основана на деталях, зависящих от архитектуры. Например если вызовы функций в области 4 КБ выполняются быстрее, имеет смысл поместить вызывающего и вызываемого рядом друг с другом.
Встраивание по объектным файлам может быть выполнено, но требует удаления настройки вызова, пролога вызываемого объекта, эпилога вызываемого объекта и обработки возвращаемого значения. Они зависят от архитектуры, поэтому для того, чтобы просто распознать их, нужен компоновщик, зависящий от архитектуры.
Различные архитектуры имеют разные форматы адресов в своих инструкциях, которые компоновщик должен знать, чтобы манипулировать ими.
Относительная адресация может привести к различным инструкциям в зависимости от размера относительного адреса.
Также существуют более сложные схемы, например для ARM.
Обычно они описываются в дополнении к спецификации формата компоновщика, например, посмотрите документы, ссылки на которые приведены в этой статье в Википедии о Формат ELF .
Некоторые инструментальные цепочки построены таким образом, что большая часть оптимизаций откладываются до времени компоновки, когда доступна информация о всей программе. Преимущества встраивания, распространения констант и многих других традиционных оптимизаций наиболее применимы при применении ко всему двоичному файлу, а не только к каждому объекту.
Некоторые компоновщики могут быть созданы для понимания нескольких архитектур. Например, я использую gnu ld, gdb, binutils и ассемблеры для своего проекта кросс-компилятора http://ellcc.org . У меня есть свой ассемблер для каждой цели, но компоновщик, отладчик и binutils понимают все процессоры. Поддерживаемые процессоры довольно разнообразны: ARM, CellSPU, Mips, MSP430, Nios2, PIC16, PowerPC, PowerPC64, Sparc, X86, X86_64.
Для разрешения адресов компоновщику необходимо, по крайней мере, знать порядок байтов и размер адресов. Некоторые архитектуры, такие как x86 в реальном режиме, имеют более сложные схемы адресации, некоторые встраивают адреса в инструкции, поэтому компоновщику может потребоваться знать поле адреса или смещения.