Почему сборка кросс-компилятора сложнее, чем сборка обычного компилятора?

Question

Все, что я прочитал, похоже, подразумевает, что создание кросс-компилятора значительно сложнее, чем создание компилятора, предназначенного для платформы, на которой он работает. Это правда? Если так, то почему? Кажется, что генерация кода ассемблера и системных вызовов для произвольной платформы не должна быть сложнее, чем генерация такого кода и системных вызовов для платформы, на которой работает компилятор, но, возможно, я просто наивен.

Answer 1

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

Для примера очень хорошо спроектированного, хорошо документированного кросс-компилятора, посмотрите lcc . Чтобы прочитать о дизайне кросс-отладчика, есть документ для конференции и докторская диссертация . Код может быть загружаемым; Я не уверен.

Answer 2

Вот некоторые проблемы, с которыми я сталкивался при работе с кросс-компиляцией GCC:

• Вам необходимо иметь некоторые системные файлы из целевой системы, присутствующие в хост-системе (т. Е. Sysroot), чтобы связываться с ними.

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

• Тестирование может быть немного более раздражающим. У вас должно быть две системы и способ переноса программы из одной в другую.

Правда, это касается общих проблем, с которыми я столкнулся.

Answer 3

Многие кросс-компиляторы имеют несколько целей. Я думаю, что в целом многоцелевой компилятор намного сложнее, чем одиночный целевой компилятор, и все многоцелевые компиляторы по определению являются кросс-компиляторами. Поэтому многие кросс-компиляторы намного сложнее, чем не кросс-компиляторы.

Написание компилятора на платформе A, который компилирует код только для платформы B, в принципе не должен быть сложнее, чем написание компилятора на платформе A, который компилируется только для платформы A.

Answer 4

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

Компилятор не только переводит исходный код в asm и системные вызовы. Он также интегрирует существующий вспомогательный код в сгенерированные файлы. Этот код включает в себя код запуска, преамбулу функций, часть C api, которая может быть встроена, и т. Д.

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

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

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

Answer 5

"Создание кросс-компилятора значительно сложнее, чем создание компилятора, предназначенного для платформы, на которой он работает."

Проблема существует из-за способа создания и доступа к библиотекам.

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

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

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

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

-Adam

Answer 6

Этот ответ на следующий вопрос может помочь вам понять, почему это будет трудно.

Почему мы не можем создавать программы кроссплатформенные в наши дни?

Я чувствую, что все сводится к тому, что разные операционные системы по-разному вызывают собственный ввод-вывод. Чтобы построить независимый от платформы компилятор, вам нужно точно знать, как работают все эти мелочи, и, в основном, собрать ОС.

[Я обновлюсь, когда вернусь домой, так как мне сейчас нужно уходить с работы]

Answer 7

Возможно ли, что вы смотрите на конкретный случай, такой как «сборка GCC как кросс-компилятора», где «сборка» означает «компиляция», а не «запись»?

Это может быть сложнее из-за проблем, связанных с библиотеками - для кросс-компилятора вам нужны библиотеки для целевой платформы. Для компилятора «нативный» (т.е. не перекрестный) у вас уже есть целевые библиотеки.

Я с вами о том, что аспекты «создания генератора кода» одинаковы или, по крайней мере, больше зависят от архитектуры целевого процессора, чем от того, где выполняется компилятор.

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