IRC channel logs
2024-11-28.log
back to list of logs
<oriansj>unmush: thank you for continuing to solve the mono bootstrapping problem. <oriansj>aggi: yeah, TCC definitely would need serious work to support 16bit code (or more likely just a 1-3Kloc patch to add assembler support for the handful of instructions needed to support those 2 bits of code and nothing further) but it is nice to hear that your work continues to flush out the problems in TCC Linux bootstrapping. <oriansj>pabs3: nonstop is a name I have not heard for a very long time. I would have assumed it dead already (its system level support for checkpointing is nice but a bad idea when you write applications that do checkpointing by default (like databases) and already have portable support for restart) given that the line has not been marketed in more than a decade. And the smart customers would have already migrated to fault tolerant Linux <oriansj>clusters (or VMware clusters for the less tech savy) <oriansj>But yeah, rust is well on its way to becoming the replacement for C (especially given the huge amount of federal funds for that effort) <oriansj>but seriously, any excuse to kill those old Unixes with either a BSD or Linux is well worth it in the long term for bootstrapping (as we atleast have the sources for those) <aggi>oriansj: i am not sure if 16bit asm support should reside inside tinycc, depending on how a "kernel bootstrapping" patch was implemented and when related bootcode had to be processed <aggi>for example, bootstrappable already implemented various tiny loaders/kernels/compilers/assemblers <aggi>and for kernel bootstrapping tccboot can be considered - that contains mentioned 16bit bootcode <aggi>however then it would be preferable, to avoid a circular dependency against tinycc itself <aggi>for a kernel bootstrapping path such as: M2/mescc plus any 16bit assembler which could process any (re-written) 16bit setup.S/bootsect.S for tccboot, to compile/assemble tccboot, which then could compile and load kernel JiT <aggi>some earlier kernel-2.2 versions had implemented their real-mode asm with as86 compatible syntax, maybe as86 could be used, if that could be compiled with mescc <aggi>tccboot/linux-2.4.37.11 could have some advantages, such as avoiding an additional fiwix kernel stage, it got usb support, it's ready for most x86 bare metal hardware, for practical reasons <aggi>i noted the as86 setup.S/bootsect.S related task on todo, for another reasons too, since i could avoid binutils then (currently i don't need it for anything else other than kernel 16bit stuff for the i486-tcc-linux-musl.iso) <oriansj>aggi: well, I did hope to do a binutils compatible assembler and linker buildable by M2-Planet to give mescc a better ability to integrate with other C compilers. <aggi>meanwhile, i've thrown a tcc-compiled static musl linked /bin/sh at linux-2.4 and init=/bin/sh panics <aggi>intersecting this, the /bin/sh itself seems ok atop a linux-5.9, another /bin/bash from tccboot.iso/bellard works fine atop linux-2.4 <aggi>meaning, it's some ABI break between linux-2.4 and linux-5.9 <aggi>i did compile against linux-2.4 headers though, nonetheless, probably musl-libc does some incompatible syscall against linux-2.4 <aggi>which wasn't covered by some api header <aggi>to my understanding some musl-1.1.24 linked binaries are executed atop fiwix 2.0 ABI (when kernel bootstrapping is enabled) <aggi>my /bin/oksh linked against musl-1.2.2 (with patches applied), but fails atop linux-2.4 ABI with ENOSYS for set_tid_address <aggi>but ok, i'll rebuild with musl-1.1 <aggi>if that's known to work atop a fiwix 2.0 ABI it too should atop linux-2.4 <matrix_bridge><cosinusoidally> iirc Red Hat back ported nptl to the 2.4 kernel series. In theory that might help threading issues, but not sure how much work that would be to apply to your linux-tcc kernel though. But yep probably easiest to just use musl-1.1.24. <aggi>seems to be time64_t related too <aggi>thanks for the nptl hint