Hi, back on topic, i've pointed to the issue tinycc mob/HEAD is not directly bootstrappable/compilable by pnut-cc or mes-cc anylonger and how this relates to the trade-off between standards compliance and language features relied upon. Hence the route to spawn a fully capable C-compiler from macro-assembly is at stake. I've too pointed to some solutions to this problem; which, i beg your pardon, VSOBFS isn't any solution for, it doesn't have to be either, and i never implied it should be. No more no less.
On 2026-07-12 11:01, [email protected] wrote: > Dear Michael, > > On Sat, Jul 11, 2026 at 05:07:17PM +0000, Michael Ackermann via Tinycc-devel > wrote: > > VSOBFS [...] i've placed this on a different page together with > > Minix to clarify upon what the differences are and why this seems > > insufficient > > to solve some important bootstrapping issues > > I appreciate if you refrain from spreading FUD. > > Can in happen that you are still not aware that VSOBFS indeed _provides_ > complete proven source-only-based > > 1. toolchains (at you choice, tinycc or gcc which has been tested) and > 2. the OS environment needed for building, i.e. the kernel and the > relevant utilities, at your choice, Minix or Linux > > Also you can have missed that you can repeat this process on virtually > any Posix-like platform and verify that the result will be the same, > reflecting only the sources used? See, this is _the_ major criteria if VSOBFS can be considered a full system-bootstrap or not. Since it relies upon a _binary_ posix runtime environment it is _not_ some fully source based solution either. Again, this may not be relevant to yield "reproducible builds", but it's not a complete system-bootstrap. In comparison live-bootstrap/stage0/M2 implemented their tiny loaders and assemblers to spawn a system from minimal hex0.seeds; this does _not_ need a giant binary posix runtime environment to begin with _before_ that got bootstrapped itself. VSOBFS instead cannot break the "circular dependency" chain which is a critical engineering concern, regardless of security considerations which are legitimate but off-topic in the context of this thread that asked for C99 standard followed. > Readily available are runnable tinycc-20a1ebf binaries and the matching > C-libraries for both Minix and Linux, again, with proven provenance > exclusively from the corresponding sources. > > To use them to build e.g. the latest tinycc in the same clean environment > is straightforward and fully scriptable, in Bourne sh. Good! I never disputed this, but it doesn't solve some most important bootstrapping problems nor the problem tinycc mob/HEAD cannot be compiled by mes-cc or pnut-cc anylonger; the simplest solution is to keep the intermediate tcc-0.9.26 version to spawn HEAD from there, which suffices for my needs, because i can roll along with HEAD and compile a _complete_ kernel and userspace with it (to my knowledge there is no other alternative to what i salvaged with many man-years of efforts) > As an alternative, extracting the binaries to a compatible environment > of your choice (e.g. from the Linux disk image, to instead run under a > modern Linux x86_64 kernel) is of course trivial. > > ---------------------------------------------------------------------- > For extra clarity: > > Unaudited OSs och toolchains are sufficient to produce verifiably clean > toolchains solely from the corresponding sources. > > The "trusting trust" compiler backdoor problem does not stand any longer. > > Trying to imitate the 1970-s manual compiler bootstrapping on modern > hardware can be a nice exercise to study compilers and operating systems, So far, the live-bootstrap stage0/M2 compiler suite is ready to use. > but pretending to solve a security problem this way is either a sign > of naïveté or of dishonesty. tccm, the type of reasoning culminated in things like UEFI, IntelME, AMD PSP; no need to bother with 70s real-mode BIOS issues, just throwing a giant binary firmware blob at it. No need to comment upon this. Few weeks ago at least i tried to compile coreboot/seabios with gcc4 and tinycc (there's a few pieces missing for tcc). Nonetheless linux-tcc kernel runs atop AMD/fm2 coreboot just fine already. Anyway, I won't speak on behalf of live-bootstrap or where GNU guix is heading in this regard. I've forked linux-tcc kernel including some grsecurity support and updated drivers instead for that reason and backported a complete musl-libc userspace. Which seems another difference, such a system can be driven by tinycc-toolchain only 100% _without_ relying upon gcc/binutils/llvm/clang anywhere. Recently i've too hacked YASM into tiny-bootstrap which can digest the few 16bit real-mode bootcode pieces from linux-tcc just fine; i've too successfully tested bin86/as86 to yield a running linux-tcc kernel, without SMP support in this case however. (since when tinycc cannot support 16bit x86 assembly to my knowledge) Furthermore i've already put mentioned system into production as my main development host many month ago, i've just not finished re-integrating the total chaos of hundreds of patches and hacks into tiny-bootstrap (and well yes, a notable amount of patching was related to security concerns) But i rather not confuse tinycc-devel with hundreds of unrelated system-integration issues. Otherwise, my bad mood isn't related to tccm or tinycc-devel at all, but the trivial fact some hiring proceeding at a university in germany was cancelled some month ago. They've only asked for more documents and input without any contracting nor salary in return. No thanks. Hence i'm not in the mood to proceed with anything. > Cheers > /tccm > > _______________________________________________ > Tinycc-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/tinycc-devel -- Michael Ackermann
signature.asc
Description: Digital signature
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
