Board.KolibriOS.org

Я не для того столько убивался(и не только я).

Я не знаю, какова была Ваша мотивация, но, на мой взгляд,
главный результат - компилятор C работающий в KolibriOS
(а убиваться не надо было - по моему Вы перестарались ... )

перенести новый tcc

Я не думаю, что новый TCC будет давать лучший код,
но попробовать стоит.

Есть мнение что его патчить проще.

(это по поводу clang)

А это как раз то, что делать надо очень осторожно, а лучше и совсем не делать:
пусть в KolibriOS работает точно также, как и в Linux.Windows. MacOS, BSD , ...

заставить lld-link

А зачем?
Компоновщик нужен только один и ни один из существующих полностью нуждам KolibriOS
не соответствует (напимер, не умеет создавать код SPE для драйверов).
А те, что есть, ничем не хуже ld.lld в контексте KolibriOS.
По моему нужно круто доработать clink, чтоб он и PE , и COFF, и ELF32 понимал, а создавал
и binary (зачем MENUET, трудно чтоли в проект crt.asm добавить?, а лучше crt.S, чтобы FASM не тащить),
и COFF, который понимает ядро Kolibri OS, и SPE ...
И самое главное - чтобы работал в KolibriOS .

портирование gcc

Судя по описанию OsDev, если newlib портирована (а вроде как портирована),
то hosted gcc - это следующий шаг.

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

Касательно libc.obj там много что не хорошо. Я был школьником по этому мог наверзить там. Но основной идеей libc.obj было, чтобы проги на СИ работали в IMG образе. Такие как шел например. Касательно crt.S. Там в исходниках libc.obj куча файлов на GAS. Это можно сказать костыль. Мне просто было лень переписывать всю математику на FASM. То есть код на fasm там намеренный. Потому что связку tcc+fasm проще и быстрее настроить чем цельный mingw-тулчейн.

ld.lld не рабоает с PE файлами, а у нас PE библиотек очень много. По этому нужно будет 2 линкера из LLVM. В этом плане ld из binutils более универсальный интсрумент потому что его можно пропатчить на генерацию любого формата. НО если использовать binutils не знаю тогда зачем использовать шланг.

Есть мнение что его патчить проще.

(это по поводу clang)
А это как раз то, что делать надо очень осторожно, а лучше и совсем не делать:
пусть в KolibriOS работает точно также, как и в Linux.Windows. MacOS, BSD , ...

Как это не патчить?

rgimad wrote: ↑Wed Sep 07, 2022 6:21 pm все эти усилия на портирование gcc в колибри бы.. как думаете он сильно завязан на линуксовые сисколлы? fork() или что-то такое вроде как есть, потому что gcc даже на многопоток рассчитан (можно и вырубить наверно)

Основная проблема в переносимости GCC это не fork(). А отсутсвие STDIO/STDOUT. Представь что буде в кос при компиляции через GCC. Там на каждый файл будет открываться новое окно шела.

Есть ешё мылси по поводу С в колибри. Хочу их озвучить. Я не знаю на каком этапе всё превратилось в этот ад с форматами и компиляторами. В MENUET дела с этим даже сейчас я думаю обстоят проще. Там все либы статические.
Я изучал как работает загрузчик PE DLL в колибри для приложений. И это я хочу вам сказать величайший костыль. На самом деле лучше бы его и не было чем вот так. Всё бы стало намного проще если бы использовали какой нить ELF или PE по умолчанию (или производные от них форматы) об этом уже говорилась триллиард раз. Но все хотят усидеть на 2 стульях и чтобы проги были маленькие и чтобы на си с полтыка собиралось.

Некоторые товарищи уже предпринимали попытки сделать загручик PE(или StrippedPE как вам угодно). Есть патч СleverMouse полурабочий. Но мне не нравится как она это сделала, но она сделал это правильно, по уму. Но мне кажется нам по уму ненадо, потому что мы не виндовс и реактос. Я про то что загрузчик в патче CleverMouse вынесен из ядра в kolibri.dll. Есть ещё бранч ядра от Сержа KolibriPE и там загрузчик целиком в ядре(вот это мне больше нравится). И я не говорю: я сделал бы лучше. Это просто моё мнение. Просто давно уже пора сделать общий формат для всего: либ, дров, прог. Не обязательно PE можно какой нить более сжатый вариант(такой как предлагала CleverMouse например или Coldy) Пока это не будет сделано мы так и будем мучится с костыльными сборками.
PS. Извините за демогогию прёт что то.

А отсутсвие STDIO/STDOUT

Это и есть ключ ко всем проблемам в портировании ...
Я бы обобщил: проблема в отсутствии стандартного типа FILE ...
НО и проблема в том, что этот самый FILE является, на мой взгляд,
квитесенцией всего странноватого и (слегка? или совсем?) устаревшего
в POSIX стандарте (а значит и во всех libc)

Вывод: нужен приемлемый костыль для FILE .

Я пока склоняюсь к простейшему:

Не обязательно PE можно какой нить более сжатый вариант

(1) В KolibriOS для библиотек и драйверов (говоря в первом приближении) используется формат, который "у людей" используется
только как промежуточный формат - формат статических библиотек.
Для динамических библиотек используется позиционно независимый код (but not relocable object).
(До меня самого это дошло только в процессе работы над cElf)
Это не значит, что надо делать "как у людей" (ибо здесь в KolibriOS лучше, на мой взгляд), просто надо понимать,
что для того, чтобы быть круче, надо быть круче
(2) Я "поиздеваюсь" над libc.obj и проверю : насколько ELF32 libc.o сжатый kpack будет больше того, что есть в kolibri.img .

P.S.
Повторюсь, но на мой взгляд:
хорошо так , как есть, но надо свой компоновщик (довести clink до нужной крутизны)
Edit1: clink - это ответ на

нужно будет 2 линкера из LLVM

ибо стороннего компоновщика, удовлетворяющего всем нуждам KolibriOS нет и не может быть
(а бинарники собрать не может только окончательно запатченный MinGW gcc )

Valery wrote: ↑Thu Sep 08, 2022 10:41 am [Для динамических библиотек используется позиционно независимый код (but not relocable object).

В Linux, возможно это так, а в Windows (dll) чаще используются релоки, чем позиционно-независимый код (PIC). С точки зрения эффективности и размера машинного кода, релоки предпочтительнее. Разумеется, если говорить об x86-32 (для x86-64, предпочтительнее именно PIC).

turbocat wrote: ↑Thu Sep 08, 2022 8:39 am По этому нужно будет 2 линкера из LLVM. В этом плане ld из binutils более универсальный интсрумент потому что его можно пропатчить на генерацию любого формата. НО если использовать binutils не знаю тогда зачем использовать шланг.

Собирал компоновщик LLVM, при сборке генерируется программа, которая включает в себя все реализованные в LLVM компоновщики. Выбор нужного производится при запучке ключём '-flavor' или вроде того.

Но они платформо специфичны все: COFF->PE, ELF->ELF и т. п.