The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск GNU Mes 0.23, инструментария для самодостаточной сборки дистрибутивов, opennews (??), 15-Мрт-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


62. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +/
Сообщение от kusb (?), 15-Мрт-21, 14:13 
А зачем нужна раскрутка компилятора? Почему не делают просто кросс-компиляцию без промежуточных этапов наполовину готовых компиляторов? А сборка может делаться удалённо, пока компилятор не завершён.
Ответить | Правка | Наверх | Cообщить модератору

69. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +1 +/
Сообщение от Аноним84701 (ok), 15-Мрт-21, 14:27 
> А зачем нужна раскрутка компилятора? Почему не делают просто кросс-компиляцию без промежуточных
> этапов наполовину готовых компиляторов? А сборка может делаться удалённо, пока компилятор
> не завершён.

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

Проще говоря, используя сторонний бинарный компилятор для сборки "рабочего" компилятора, нельзя будет (на практике, т.к. gcc зело объемный) проверить-доказать отсутствие "встраивателя закладок" в результате работы этого стороннего компилятора.

Ответить | Правка | Наверх | Cообщить модератору

74. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +2 +/
Сообщение от Аноним (74), 15-Мрт-21, 15:04 
Так ведь всё равно никак не получить готовый бинарный компилятор без другого готового бинарного компилятора.
Ответить | Правка | Наверх | Cообщить модератору

75. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +/
Сообщение от Аноним (53), 15-Мрт-21, 15:15 
> Так ведь всё равно никак не получить готовый бинарный компилятор без другого
> готового бинарного компилятора.

Оттранслируй ассемблер в машинные коды вручную если не доверяешь машинным кодам полученным из этого ассемблера (которые можно прочитать). Вон в соседней ветке есть пример.

Ответить | Правка | Наверх | Cообщить модератору

94. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +5 +/
Сообщение от Аноним (40), 15-Мрт-21, 16:11 
А откуда взялся самый первый компилятор? Из большого взрыва?
Ответить | Правка | Наверх | Cообщить модератору

101. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +2 +/
Сообщение от Аноним (27), 15-Мрт-21, 16:35 
с перфокарты
Ответить | Правка | Наверх | Cообщить модератору

147. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +/
Сообщение от Sw00p aka Jerom (?), 15-Мрт-21, 23:08 
"курица или яйцо" :) Самая первая версия ГЦЦ каким компилятором собиралась?
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

162. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +1 +/
Сообщение от Аноним (162), 16-Мрт-21, 09:45 
Надо прочесть историю о Bell Labs, машине PDP, и двух отважных героях, которые в конце 1960-тых решили, что лучше синица в руках чем журавль в небесах. Придумали C, написали его компилятор на ASM и на C написали первый UNIX.
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

210. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +/
Сообщение от Аноним (-), 17-Мрт-21, 15:11 
> А откуда взялся самый первый компилятор? Из большого взрыва?

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

А так то один раз журнал "для умелых рук" прикололся и хексдамп аж всего CP/M напечатал. Поэтому губитель спаявший комп имел некие шансы вбить сие с шестнадцатиричной клавиатуры - и обана - вместо мертвого металла у вас ОПЕРАЦИОНКА, ЦУКО.

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

212. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +/
Сообщение от n00by (ok), 17-Мрт-21, 15:28 
> А так то один раз журнал "для умелых рук" прикололся и хексдамп
> аж всего CP/M напечатал. Поэтому губитель спаявший комп имел некие шансы
> вбить сие с шестнадцатиричной клавиатуры - и обана - вместо мертвого
> металла у вас ОПЕРАЦИОНКА, ЦУКО.

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

Ответить | Правка | Наверх | Cообщить модератору

135. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  –1 +/
Сообщение от Lex (??), 15-Мрт-21, 20:56 
Хм, т.е как про облачную сборку или применение готовых бинарников компилятора - так рассказы про не_доверие третьей стороне и отсутсвие проверки на закладки.

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

п.с: а если я не доверяю сгенерированному ассемблерному листингу ?
Ведь вопрос даже не в том, как конкретно он переведется в машинные команды, а в том, какая логика и алгоритмы в нем заложены

Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

76. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +1 +/
Сообщение от n00by (ok), 15-Мрт-21, 15:24 
Можно первый компилятор перевести в машинный код вручную. На деле именно эта задача автоматизируется: сначала собирается ассемблер, затем он транслирует небольшой по объёму компилятор, тот более сложный.
Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

77. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +/
Сообщение от Аноним (27), 15-Мрт-21, 15:24 
да, но MesCC не требует компиляции, поскольку написан на Scheme. Можно предположить, что интерпретатор (который как раз бинарный) с закладками, но тогда этот интерпретатор должен распознать, что выполняется код MesCC и следует подложить закладки в собираемый бинарник. Ведь собираемый бинарник может оказаться интерпретатором, на котором потом запустят MesCC и соберут нормальный TinyCC
Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

78. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +/
Сообщение от Аноним84701 (ok), 15-Мрт-21, 15:28 
> Так ведь всё равно никак не получить готовый бинарный компилятор без другого готового бинарного компилятора.

Неа.
> Интерпретатор языка Scheme достаточно компактный, занимает около 5000 строк кода на простейшем подмножестве языка Си и может быть преобразован в исполняемый файл с использованием универсального транслятора M2-Planet или простейшего Си-компилятора, собранного с использованием самособираемого ассемблера hex0, не требующего внешних зависимостей. <- this
>(hex0) The stage0 is the ultimate lowest level of bootstrap that is useful for systems without firmware, operating systems nor any other provided software functionality Those with such capabilities can skip this stage as it requires human input.

Хотя основная идея конечно -- чем минималистичнее "изначальный" бинарь, тем проще валидация.

Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

134. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +/
Сообщение от Lex (??), 15-Мрт-21, 20:48 
Чем больше этапов, модулей и применяемых ЯП - тем проще проверять ?)
Ответить | Правка | Наверх | Cообщить модератору

137. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +/
Сообщение от Аноним84701 (ok), 15-Мрт-21, 21:17 
> Чем больше этапов, модулей и применяемых ЯП - тем проще проверять ?)

Естественно это проще, чем проверять бинарь "полноценного" Си-компилятора на соответствие исходному коду ( в том же TCC более 50 000 строк кода -- удачи и терперния с реверсингом всех 200-300KB бинарника).

> Since version 0.22 it has again helped to halve the size of opaque, uninspectable binary seeds that are currently being used in the Reduced Binary Seed bootstrap of GNU Guix.
> The final goal is to help create a full source bootstrap as part of the bootstrappable builds effort for UNIX-like operating systems.

Ответить | Правка | Наверх | Cообщить модератору

185. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +/
Сообщение от Аноним (185), 16-Мрт-21, 17:07 
> Чем больше этапов, модулей и применяемых ЯП - тем проще проверять ?)

Че больше автоматизация, тем легче верификация!

https://github.com/oriansj/stage0 надо руками с клавиатуры вколотить бинарь всего 1000 байт stage-0.

Stage-1 трижды пересобираем ASM от самого примитивного stage1_assembler-0 до вполне рабочего stage1_assembler-2 и макрос M0 (M1) можно уже этот этап автоматизировать.

Stage-2 компилятор Lisp (Scheme)

Stage-3 самый примитивный компилятор C на Lisp (Scheme)

Это то что надо сделать сегодня. И вполне реально.

А вот как долго рождался первый компилятор C: https://www.opennet.ru/openforum/vsluhforumID3/123569.html#168 для сравнения.

Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

183. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +/
Сообщение от Аноним (185), 16-Мрт-21, 16:56 
> или простейшего Си-компилятора, собранного с использованием самособираемого ассемблера hex0, не требующего внешних зависимостей. <- this

Неа! Нету C на ASM!!!


А вот Lisp на ASM есть! Именно по этому для написания простейшего компилятора C был выбран Scheme: https://www.opennet.ru/openforum/vsluhforumID3/123569.html#181

Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

192. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +/
Сообщение от Аноним84701 (ok), 16-Мрт-21, 17:52 
>> или простейшего Си-компилятора, собранного с использованием самособираемого ассемблера hex0, не требующего внешних зависимостей. <- this
> Неа! Нету C на ASM!!!

Ну нету так нету -- раз аноним так говорит, то ему видней.

https://bootstrapping.miraheze.org/wiki/Stage0
> cc_* + family[edit]
> These are C compilers targeting a single architecture written in assembly
> that support the following primitive types:

   void (and void*)
   int (and int*)
   char (char* and char**)
   FILE (and FILE*)
   FUNCTION (and FUNCTION*)
   unsigned (and unsigned*)
   long (and long*)

> Which can be combined with struct and within structs, one may union members.

https://github.com/oriansj/stage0/blob/master/stage2/cc_amd64.s
> ;; A Minimal C Compiler

...


;;    struct token_list* out in R12,
;;    struct token_list* string_list in R11
;;    struct token_list* global_list in R10
;;    and struct token_list* FUNC in R9
;;    and struct token_list* current_target in R8
;; R13 Holds pointer to global_token, R14 is HEAP Pointer
;; Returns the token_lists modified
:postfix_expr_stub
    PUSHR R0 R15                ; Protect R0
    PUSHR R1 R15                ; Protect R1

    LOADUI R0 $open_bracket     ; Using "["
    LOAD32 R1 R13 8             ; GLOBAL_TOKEN->S
    CALLI R15 @match            ; IF GLOBAL_TOKEN->S == "["
    JUMP.Z R0 @postfix_expr_stub_next


Ответить | Правка | Наверх | Cообщить модератору

201. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +/
Сообщение от Аноним (203), 17-Мрт-21, 08:16 
> Ну нету так нету -- раз аноним так говорит, то ему видней.
> https://bootstrapping.miraheze.org/wiki/Stage0
> cc_* + family[edit]
> M2-Planet

cc_* и M2-Planet - не есть компиляторами C. Анон это первый раз видит, синтаксис C но функционал ASM.

Примитивный компилятор C все равно собирает Lisp (Scheme): https://github.com/oriansj/stage0-posix

Seed in HEX (машинные коды)
0: Rebuild hex0 from the hex0 seed

ASM (асемблер)
1: Build hex1 from the Phase 0 hex0
1b: Build catm from Phase 0 hex0
2: Build hex2-0 from hex1
3: Build M0 from Phase 2 hex2-0

Pre C (это не C)
4: Build cc_* from M0

M2-Planet Pre C (и это не C)
5: Build M2-Planet from cc_*
Debug
6: Build blood-elf-0 using M2-Planet

Cross-platform
7: Build M1 implementation in M2-Planet
8: Build hex2 implementation in M2-Planet

Script interpretator (автоматизация)
9: Build kaem
10: Build blood-elf implementation in M2-Planet
Phase 11: Build get_machine
12: Build M2-Planet from M2-Planet
13: Build Mes-M2 using M2-Planet
"The Scheme interpreter is written in ~5,000 LOC of simple C, and the C compiler written in Scheme and these are mutual self-hosting. This mes.c is now being simplified to be transpiled by M2-Planet."
14: Build Mes-Scheme (Lisp) using M2-Planet https://git.savannah.gnu.org/cgit/mes.git/tree/src/ код на "Cross-platform M2-Planet Pre C

C (примитивный компилятор C)
15: Build MesCC using Mes-Scheme (Lisp) https://git.savannah.gnu.org/cgit/mes.git/tree/build-aux код на Scheme (Lisp)
16: Build TinyCC using MesCC
17: Build GCC using TinyCC

Обратите внимание на фазы 14 и 15. В теории 14 можно легко преобразовать в ASM (затруднит верификацию и потеряется кроссплатформенность 7-14). А вот 15 на ASM говорят написать не получается!!!

Ответить | Правка | Наверх | Cообщить модератору

79. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +/
Сообщение от Аноним (27), 15-Мрт-21, 15:29 
> А зачем нужна раскрутка компилятора?

чтобы собрать компилятор
>Почему не делают просто кросс-компиляцию без промежуточных этапов наполовину готовых компиляторов?

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

Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

173. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +2 +/
Сообщение от Ordu (ok), 16-Мрт-21, 13:25 
Когда ты собираешь компилятор предыдущей версией компилятора, возникает интересная проблема, что ежели по каким-то причинам существующие компиляторы тебя не устраивают, то ты ничего изменить не можешь. Скажем была теоретическая концепция вируса, живущего в компиляторе, и инфицирующая всё, что собирается компилятором. В том числе и последующие версии компилятора, чтобы они делали то же самое. При подходе "следующая версия компилятора компилирует предыдущую" этот вирус неуловим.

Могут быть и другие нюансы, но суть в том, что ты вынужден доверять компилятору, и _всей_ _истории_ предыдущих сборок этого компилятора, что нигде в прошлом никто не инфицировал компилятор. Откуда ты знаешь? Чем собиралась первая версия gcc? Я допустим не знаю, и не знаю могу ли я доверять ей. Более того, в моей системе gcc пересобирает сам себя уже лет десять, по-моему. В любом случае всё началось с gcc из гентушного stage-3. Но гентушный stage-3 компилятор был собран предыдущей версией гентушной сборки gcc. А если мы отследим назад в прошлое, то откуда был взят компилятор, которым первая гентушная сборка gcc была собрана? А впоследствии точно нигде никто не сделал с этой сборкой ничего такого?

В linux'е очень долго не было никаких процессов для мониторинга бинарей. Сейчас есть воспроизводимые сборки, это хоть что-то. Но этого недостаточно. Мы можем, скрестив пальцы, рассчитывать, что тысячи глаз вычистят сорцы от хлама, но если хлам в бинарях и распространяется от бинаря к бинарю? Найдётся хоть один глаз, который будет искать?

Хочется историю отрезать, и доверять какому-то воспроизводимому техпроцессу. Нельзя сказать, чтобы сегодня вся эта хрень решала бы какую-то _практическую_ проблему, но в целом можно лишь приветствовать попытки запилить техпроцесс создания компилятора "с нуля", потому как даже если когда этот техпроцесс окажется востребованным, он окажется неприменимым на практике (потому как создавался не под решение конкретной практической проблемы, а пальцем в небо), то по-крайней мере накопленный опыт создания техпроцесса окажется полезным.

Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

182. "Выпуск GNU Mes 0.23, инструментария для самодостаточной сбор..."  +/
Сообщение от Аноним (185), 16-Мрт-21, 16:48 
> В любом случае всё началось с gcc из гентушного stage-3. Но гентушный stage-3 компилятор был собран предыдущей версией гентушной сборки gcc. А если мы отследим назад в прошлое, то откуда был взят компилятор, которым первая гентушная сборка gcc была собрана? А впоследствии точно нигде никто не сделал с этой сборкой ничего такого?

https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../

Проходил бутстрап начиная со stage1 и много чего дополнительного. Он должен быть чист.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру