Board.KolibriOS.org

We have official toolchain based on GCC. So, I think we can drop support compile by other compiler and left toolchain by Serge and TCC (because we have port on KolibriOS).

Motivation:

1. Unify of C/C++ ecosystem
2. Reduce number of tools for building and simplify build environment

In this case, we should port to GCC or TCC next programs:

• kosilka
• xonix
• fara
• rforces
• graph
• table
• ac97snd

What do you think about it?

Strongly agree, the simpler almost always the better.

But maybe folks here will find stuff unable to be done with GCC and TCC

Boppan wrote:But maybe folks here will find stuff unable to be done with GCC and TCC

I am sure that near to impossible. Other hand, if it happened, we should improve these 2 compilers and libraries.

Last time, I didn't see any new program that compiled by others compilers. And it's too expensive for us, try to support a lot of C/C++ tools and libraries for each one.

Unfortunately, Serge's toolchain without Serge is an outdated binary blob: nobody knows how to compile or update it.

In this case, we should port to GCC or TCC next programs: kosilka, xonix, fara, rforces, graph, table, ac97snd

How far is this task? (Насколько удалось продвинуться в этом направлении?)

Unfortunately, Serge's toolchain without Serge is an outdated binary blob: nobody knows how to compile or update it.

It's bad - it seems that Serge's toolchain is the only possibility to compile KolibriOS library, written in C.
kos32-gcc -c produce coff object file witch KolibriOS kernel understands (after llvm-objcopy or OsDev cross compiler objcopy too).
llvm-objcopy or OsDev cross compiler objcopy can convert modern compiler's elf to coff, but KolibriOS kernel interprets this coff-file
with errors.
P.S.
For simple programs I use OsDev style cross-compiler with fasm crt.asm , but mostly Debian Clang-LLVM toolchain
with -m32 and some free standing options can be used too (for OsDev style work too).

Is there sources of gcc-patch from Serge?

Is there sources of gcc-patch from Serge?

I think it is not a patch, but only customized build (mostly based on MinGW/Msys old build, and before there was Diamond (one of the Kolibry "founders") variant).
But I really don't know ...

I was tried to build gcc-coff cross compiler variant (on old MSys), and was able only build binutils (ver. 2.29). I was not able build gcc 7.2.0 i686-coff-gcc .
But I was not trying to build ver. 6 or ver 5. And I was not trying to build cland/LLVM compiler with coff option.

It seems, that modern c/c++ compilers not support coff format on i686 ...

I in a week will try again to build i686-coff-gcc and not only on MSys , but on my Linux (amd64, Debian Stable (2022.08.23)) computer.

Valery wrote: ↑Tue Aug 23, 2022 1:48 am It's bad - it seems that Serge's toolchain is the only possibility to compile KolibriOS library, written in C.
kos32-gcc -c produce coff object file witch KolibriOS kernel understands (after llvm-objcopy or OsDev cross compiler objcopy too).
llvm-objcopy or OsDev cross compiler objcopy can convert modern compiler's elf to coff, but KolibriOS kernel interprets this coff-file
with errors.

Also there's a COFF to COFF linker written specially for KolibriOS purposes: https://github.com/mkostoevr/clink
It can link multiple .o coff files into one coff file, very needed if you want to make KolibriOS libary from multi-file C/++ project

Valery wrote: ↑Tue Aug 23, 2022 1:48 am

In this case, we should port to GCC or TCC next programs: kosilka, xonix, fara, rforces, graph, table, ac97snd

How far is this task? (Насколько удалось продвинуться в этом направлении?)

I looked, as they were on MSVC and they are, so the problem is still relevant.

I looked, as they were on MSVC and they are, so the problem is still relevant.

In this case my idea is to rewrite this programs (kosilka, xonix, fara, rforces, graph, table, ac97snd) to C/FASM so, that
ktcc & fasm will be able to compile this programs. (But I will use my stile: clang + fasm).

If nobody stops me in a week I will start work with one of (...) .

Edit1 (OffTop): I know about this clink : <KolibryOS websvn>(root)/programs/develop/clink/ .
If it is the same, than clink do not change situation: clink not convert "bad" coff to "good" coff, only combines "good" coff files into one.
Problem with coff, produced by other tools (not fasm , kos32-gcc), may be one of (may be both):
(1) KolibriOS kernel support's coff only partially - support only coff files, produced by fasm (and kos32-gcc simply use the same part off coff specification) ;
(2) modern objcopy programs use maximal coff extensions to keep maximum of (for example) elf object file features.
Edit2: It seems that problem is in relocation record types:
kos32-gcc and i386-coff-as (-gcc?) produce IMAGE_REL_I386_DIR32
clang, gcc, i686-elf-gcc produce R_386_32 , and converted by all objcopy to IMAGE_REL_I386_DIR16 (and with value EXPORTS : not .text).
Is this relocation type supported by KolibriOS kernel?

Some information from SVN , and some my comments about rewrite task:

kosilka (main distro :: leency :: 2018.09.12 :: /programs/games/kosilka/)

Style: C with classes but with strange this->...
(1) Use my own SysCall wrappers,
(2) use newlib or (may be) libc.obj sprintf(...)
(3) use my standart asm crt.h

xonix (main distro :: yogev_ezra/dunkaist :: 2017.11.21 :: /programs/games/xonix/)

Style: real C++ hardened with inline assembler ...
(1) some files are common with kosilka

fara ( - but was :: yogev_ezra/dunkaist :: 2017.11.21 :: /programs/games/fara/)

Style: C with classes but with strange this->... but some templates are
The most complicated - most massive game ....

rforces (main distro :: yogev_ezra/leency :: 2018.10.31 :: /programs/games/rforces/)

Style: C with classes, mostly C
The simpliest one

graph (main distro :: barsuk/leency/vitalkrilov :: 2022.04.24 :: /programs/other/graph/)

Rewrite is done by vitalkrilov! Why is not used ? Edit: I think - is used , but code is not portable - so really not done ...
Edit: But original can not work, so used vitalkrilov version - and in this case is done!

table (main distro :: barsuk/leency :: 2020.05.10 :: /programs/other/table/)

Style: C , but use common C++ files
May be this is simpliest one ....

ac97snd (main distro :: serge/leency :: 2018.03.07 :: /programs/media/ac97snd/)

Written in C , not C++ , so may be it can be build with minimal changes ...

Edit1: graph is done in so TCC KOS port way, that could not be compiled by generic cross compiler.
tcc port "over automation" = vitalkrilov work is not portable.
As tcc not produce good code (it is small) => rewrite is not done...
So I started my own graph rewrite from scratch ...
Edit2:I started work with graph ...
Edit3:I started work with ac97snd {2022.09.05}

Я так сильно ошибся что теперь не знаю что и делать.
До меня дошло сейчас осознание что TCC(особенно его старая версия которая у нас сейчас) выдаёт крайне не оптимальный код а иногда и странный (jmp перед ret на ret передаёт привет).
Ещё и людей подтолкнул на использования этой фигни(да да Simargl был прав он игрушечный).
Но есть что есть. Ситуация может улучшится если попытатся портировать новый TCC там код более оптимальный.

Касательно того тулчейна что мы имеем... Это обычный MinGW.
Я собирал новым MinGW либы и некоторые проги кос. Все работало.
Было бы здорово нормально пропатчить новый MinGW чтобы он выплёвывал бинарники колибри стразу без махинаций с LD скриптами и прочими утилитами.
Ещё один камень предкновения это зоопарк форматов. Из-за этого не понятно на что его патчить: на генерацию PE?, MENUET, или COFF(хотя coff можно слипить с помощью ключа -r)

все эти усилия на портирование gcc в колибри бы.. как думаете он сильно завязан на линуксовые сисколлы? fork() или что-то такое вроде как есть, потому что gcc даже на многопоток рассчитан (можно и вырубить наверно)

Я так сильно ошибся что теперь не знаю что и делать.

Извините, если я выскажусь слишком резко, но на мой взгляд у Вас turbocat какой-то подростковый максимализм ...
TCC -это вполне хороший компилятор и он в духе KolibriOS, ибо
имеет размер сравнимый с FASM, но он и ассемблер (в стиле GNU), и компоновщик (linker), и компилятор полноценного C,
и код выдаёт получше, чем тот, что при -O0. Если TCC считать игрушечным, то тогда можно и саму KolibriOS
считать игрушечной но тогдаь всё равно имеется адекватное соответствие между TCC и KolibriOS (:оба игрушечные).
(а странный код выдаёт и clang при -Oz, поэтому и "прокатывает лозунг": "Операционная система, написанная на ассемблере" )

Другое дело, что его не надо бы использовать в автосборке, ибо есть средства лучше . что автоматически
означает, что C - код не должен быть специфическим для TCC, а ткже для MinGW, VisualC.
На мой взгляд, С - код должен компилироваться OsDev кросскомпилятором без единого предупреждения.

Это обычный MinGW.

А вот с этим я Вас всех и поздравляю - MinGW является очень специфическим средством разработки
(поэтому в своё время отдельно отмечался как средство непригодное для OsDev,
но сейчас просто строго рекомендуется gcc cross compiler, ибо для нужд дистрибутивов gcc так кофигурируют,
что "мама - не горюй", поэтому я и использую clang).
У меня даже есть подозрения, что в ядре KolibriOS поддерживается COFF не полностью а в духе FASM/MinGW.

На мой взгляд, TCC - это вообще не проблема ибо (из существенных ...) только Ваша, turbocat libc.obj собирается
при помощи TCC, но (я это дело пробовал) эта библиотека собирается и посредством kos32-gcc (и, если вписать на GNU asm, ту пару функций, что написаны на FASM) по прямой.

Поэтому, если отвечать на вопрос :"Что делать?", то надо просто
(1) перевести всё, что сейчас в автосборке собирается посредством TCC, на kos32-gcc,
(2) самым пристальным образом обратить внимание на OsDev кросс компилятор
(а вот это уже не просто, ибо похоже что у Вас всё сильно специфически "заточено под KolibriOS")
(3) в ядре требуется полноценная поддержка COFF (у меня есть подозрение, что тогда и SPE окажется не нужен)
однако по поводу COFF - это отдельный разговор, ибо COFF похоже безнадёжно устарел на i686.

Ещё раз повторяю: извините, если я выскался слишком резко ... Но и без резкой критики как-то не обойтись ...

Да меня шатает иногда). На самом деле раньше libc.obj так и собиралась с помощью kos32-gcc, но от этого проблем больше чем плюсов. Дело в том что он собирал некоторые куски кода с нулевой оптимизацией, потому что в tcc и gcc разные способы передачи структур в функции. Из за этого я решил её собирать таким образом. То что автособирается tcc и будет им собираться. Я не для того столько убивался(и не только я). Линковка libc.obj это вообще отдельная тема. По этому хорошим решением будет перенести новый tcc. Касательно тулчейна хз. Можно и кланг юзать. Есть мнение что его патчить проще. Серж сделал загрузчик PE в юзерспейсе и многие проги юзают PE DLL. Хз можно ли заставить lld-link генерить и MENUET и PE.