LINUX.ORG.RU

Ответ на: комментарий от anonymous

1. сборка нового gcc старым (с оптимизацией или нет - я не помню)
2. сборка новым нового без оптимизаций
3. сборка нового с оптимизациями новым без оптимизаций.

что-то вроде такого, хотя могу ошибаться - бутсрапил гцц очень давно.

jr_A
()

http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-pass1.html

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

generatorglukoff ★★
()
Ответ на: комментарий от jr_A

>1. сборка нового gcc старым (с оптимизацией или нет - я не помню) 2. сборка новым нового без оптимизаций 3. сборка нового с оптимизациями новым без оптимизаций.

/me сломал моск, ниасилив

Osmos ★★
()
Ответ на: комментарий от jr_A

>2. сборка новым нового без оптимизаций

А эта стадия зачем?

KRoN73 ★★★★★
()
Ответ на: комментарий от jr_A

> что-то вроде такого

Не совсем так.

1. Сборка нового старым
2. Сборка нового результатом шага 1
3. Сборка нового результатом шага 2
3a. Сравнение объектных файлов от шагов 2 и 3. Если хотя бы один файл различается, сборка считается неудачной.

AEP ★★★★★
()
Ответ на: комментарий от AEP

Да, промахнулся слегка, спасибо за замечание.

jr_A
()
Ответ на: комментарий от birdie

> Раньше собиралось всё в одну стадию

Раньше все _по_умолчанию_ собиралось в одну стадию, но можно было сделать make bootstrap. Сейчас make и make bootstrap делают одно и то же.

AEP ★★★★★
()
Ответ на: комментарий от AEP

А bootstrap можно отменить в новых GCC?

Честно говоря, бесит ждать почти час (точно не помню - не засекал) на достаточно мощном 2х ядерном CPU, пока оно соберётся.

birdie ★★★★★
()
Ответ на: комментарий от AEP

>3a. Сравнение объектных файлов от шагов 2 и 3. Если хотя бы один файл различается, сборка считается неудачной.

а при каких ключах это наступает?

madcore ★★★★★
()
Ответ на: комментарий от madcore

> а при каких ключах это наступает?

Этого я ни разу не видел. Цель проверки - убедиться, что gcc собирает себя правильно.

Результат первой стадии представляет собой двоичный код, который делает в точности то, что написано в исходниках gcc (возможно, медленно, если старый компилятор не умеет оптимизировать как следует). Результат второй стадии делает то же самое, и, кроме того, сам собран по правилам, написанным в исходниках gcc (т.е. сам компилятор как двоичный файл может отличаться от первой стадии, но обязан давать то же самое в выходных файлах). Результат третьей стадии получается из тех же исходников по тому же алгоритму преобразования в машинный код. При обнаружении отличия от второй стадии следует немедленно сообщить об ошибке в gcc или о серьезно поломанном первоначальном компиляторе.

AEP ★★★★★
()
Ответ на: комментарий от birdie

>С помощью ассемблера, друг мой.

Ага, а ассемблер святым духом вводился? :) В начале было программирование перемычками и переключателями. Потом - ввод двоичных данных через "монитор" (BIOS + микроОС в ПЗУ). Потом уже - рост сложности ассемблеров :)

...

Мой путь в компы начался с ручного ввода машкодов через монитор "РК-86" :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Мы же про одну стадию до говорим. До перемычек были наскальные рисунки ;-)

birdie ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.