Я не знаю, какова была Ваша мотивация, но, на мой взгляд,Я не для того столько убивался(и не только я).
главный результат - компилятор 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 .
Судя по описанию OsDev, если newlib портирована (а вроде как портирована),портирование gcc
то hosted gcc - это следующий шаг.
P.S.
По поводу libc.obj - это отдельный разговор, я на неделе как нибудь напишу, что
мне не нравится в исходном коде libc.obj (разумеется не здесь - для libc.obj существует от дельная тема)