Sigh. On 2026-07-13 18:43, [email protected] wrote: > On the other hand, the hex0 to tcc-0.9.26/janneke bootstrap is a fully > > verifiable source path. > > This is, sadly, not true. > 1. hex0 is not a source, but the codes, exactly as they are to be > interpreted by the CPU. It is expected to be interpreted by the CPU, right? > The comments are irrelevant for verification, they are not the code.
#bootstrappable argued all the hex seeds were hand-written, reviewed, inspected and documented with great efforts, you can't have any better than this and it is tiny ~500bytes to begin with. In comparison any binary posix runtime environment required by VSOBFS for example is millionfold the size to dis-assemble for inspection, just in case that was necessary anytime for forensics. If tccm discards the stage0-posix hex0 seeds, even then the same critique holds true for VSOBFS itself, which in fact is plagued even worse by a much bigger "circular dependency" graph of binary artifacts involved. Although this is a common problem with almost all typical *nix systems nowadays. And at some point, it's axiomatic almost to assume hand-written machine code is executed correctly on the hardware. Otherwise you might have to cope with hardware-development (which there is relevant projects involved with this, oa486 FPGA for example), but that's a separate concern and not specific to any bootstrapping/toolchain variant, if you wished to trust hardware/firmware. > Then what was the point, besides the "hack value", of using the chain > from the machine code to intermediate stages to C99, when you can as > well and safely begin from C99? C-compilers written in assembly are extremely challenging hence it's a bliss pnut-cc or mes-cc can be compiled with M2 compiler-suite to derive i386-tcc directly from this. As a side-effect the binary artifact "trusting trust" issue on the software-side is void then, almost. With VSOBFS instead it isn't nowhere near hence the reliance on "reproducible builds" across different hosts then, which can be a reasonable approach too - it's never been disputed - and there is many of these kind. But this isn't a full system-bootstrap by definition. On 2026-07-14 11:39, [email protected] wrote: > On Mon, Jul 13, 2026 at 08:44:22PM +0200, Aleksandar Kuktin wrote: > > Certainly, it is not logically necessary to bootstrap the new system. > > Yet, ordinarily, a newly invented system will at some point bootstrap > > itself to prove it's sufficiently capable to carry the full load of > > information processing. > > This is something I must have missed? Did e.g. Linux on riscv bootstrap > itself from machine code, without using cross-built bootmedia and > compilers? I assume "no". Exactly, there is no complete/direct system-bootstrap for riscv64|aarch64 with tinycc to arrive at a complete POSIX. It's somehow ironic given the amount of money thrown at riscv64|aarch64. Hence at least one other complete system bootstrap should remain, that is the one from live-bootstrap for x86_32 "only", so all other ARCH can be cross-compiled from there as usual just like that's done with any system which was _not_ derived from a full system bootstrap alike. This problem is solved. tccm, if you prefer a non-bootstrapped development host for cross-compilation that's fine, but other developers might have different opinions on this for _very_ good reasons which were outlined already. Due to this I too would argue at least one POSIX development host for at least one ARCH=x86_32 including kernel/libc/userspace should be supported with tinycc 100% _without_ relying on gcc/binutils/llvm/clang/c++ anywhere (thats the priority of tiny-bootstrap), because this too establishes a baseline to retain portability with alternative *nix C-toolchains overall (cproc/qbe/kefir/chibicc/simple-cc/pcc). Meanwhile developers among live-bootstrap implemented various pieces for riscv64 already, but there is many blockers remaining, somehow related to tinycc-devel, since i've seen backports for riscv64 onto tcc-0.9.26 even because mentioned re-base was missed (yet there remains that many other issues with aarch64|riscv64 and kernel mainly i rather not continue to argue with this) Furthermore there is legitimate criticism of some technical aspects of live-bootstrap (for example thats why MES-replacement seeked to implement some compile-time dependency tracing into earliest bootstrapping stages which remain rather complex and very difficult to review tbh). Among others I have not yet encountered one such reasonable criticism of live-bootstrap from tccm although this thread seems to arrive at a tautological dead-end due to this... See: > This is a circular argument - the usefulness of doing X is that we know > that X is possible. Why would we _need_ X remains unanswered. Noone here argued neither bootstrapping must be done nor tinycc-devel must have prioritized it's internal implementation details concerning C-standard followed and language features relied upon related to bootstrapping. > > at one point you yourself reject the > > notion VSOBFS can serve it's purpose without bootstrapping. It can't and it doesn't have to either, exactly. And again I have no clue why tccm feels urged to discreditlive-bootstrap with false premises then (it's moot to cite those yet again). And this certainly is off-topic and in-appropriate, in particular since when VSOBFS denies several design rationales that were crucial to live-bootstrap. Other than this, the limited scope of "re-producible builds" remains a relevant option too, of cause, for that matter there is rather many of this kind of approaches besides VSOBFS, and it's _never_ been disputed by anyone either these too were relevant to ensure integrity of binary artifacts produced with tinycc. On 2026-07-13 14:18, Ivo van Poorten wrote: > On the other hand, the hex0 to tcc-0.9.26/janneke bootstrap is a fully > verifiable source path. Yes, hence I only allowed myself to argue the issue with tcc-0.9.26 should be kept in mind, since this is the most plausible solution (without any other known currently). No idea why tccm is denying this. I have no clue at all either why tccm argues for VSOBFS which neither adresses a complete system-bootstrapping option nor C-standard followed and language features relied upon related to this. -- Michael Ackermann
signature.asc
Description: Digital signature
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
