Drop extra compilers

High-level languages programming questions

POLL Should do we drop other compilers?

Total votes: 9
Yes
67%
6
No
33%
3

  • Касательно 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 .

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

    Code: Select all

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

    P.S.
    Повторюсь, но на мой взгляд:
    хорошо так , как есть, но надо свой компоновщик (довести clink до нужной крутизны)
    Edit1: clink - это ответ на
    нужно будет 2 линкера из LLVM
    ибо стороннего компоновщика, удовлетворяющего всем нуждам KolibriOS нет и не может быть
    (а бинарники собрать не может только окончательно запатченный MinGW gcc :evil: )
  • 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 и т. п.
  • Who is online

    Users browsing this forum: No registered users and 2 guests