IRC channel logs

<aggi>this commit is breaking linux-2.4 kernel compilation with tcc 8e860702e44ca1279098e0fc2142ad579774b1d2

<aggi>i've bisected through more than 100, not sure if there's more

<aggi>git revert on some recent mob branch commit causes a merge conflict... a little pain awaits

<aggi>i'll try first to manually backing out this one commit, and see if this suffices

<aggi>and it seems a principle problem, tcc is/was not tested against linux-2.4 kernel compilation for several years

<fossy>cosinusoidally no surprises there lol, mob seems somewhat perenially buggy in someway or another

<matrix_bridge><cosinusoidally> 8e860702e44ca1279098e0fc2142ad579774b1d2 is such a typical tcc commit. No discussion on the mailing list, no code review, and introduces a subtle bug that goes unnoticed for several years.

<matrix_bridge><cosinusoidally> btw I managed to figure out a simpler way to get code in and out of the live-bootstrap version of fiwix. The answer was to use the floppy drive. I had to inject a fiwix busybox binary and an approx 10 line shell script (to set up device nodes). I tried building busybox-1.01 inside live-bootstrap but it doesn't seem to like musl libc.

<matrix_bridge><cosinusoidally> busybox sh works fine with an interactive terminal inside live-bootstrap

<matrix_bridge><cosinusoidally> I was able to build dash. Only issue I ran into was that tcc-musl is missing alloca. I had to compile tcc-0.9.27/lib/alloca86.S and link it in.

<matrix_bridge><cosinusoidally> dash also seems to work fine with an interactive terminal.

<aggi>ACTION sighs

<aggi>commit 8e860702e44ca1279098e0fc2142ad579774b1d2 cannot easily be reverted

<aggi>this is 2.5years of changes made

<aggi>to tcc mob branch

<aggi>i did a quick revert at some HEAD from march 2023 (didn't sync since then), but there's obviously more stuff that breaks kernel-2.4 compilation/linking

<aggi>in between it is 140commits already, plus the ones until November 2024, to identify exactly which and how many were breaking linux kernel compilation/linking

<aggi>i don't want to fork/branch, but rather rebased all necessary changes/reverts onto latest HEAD

<aggi>it is alot of work, to follow hundreds of commits, and so far I only spotted one that broke linux kernel

<aggi>and there's probably more

<aggi>furthermore, since tcc is crucial to bootstrappable, the changes are related to ELF sections and linking, affecting _all_ architectures, if anytime a kernel shall be compiled/linked for any other arch than X86

<aggi>that's why, i rather saw HEAD of the mob branch remaining tested against linux-2.4 kernel compilation for x86 at least

<aggi>because, the changes that were breaking things, potentially affect various other test cases

<aggi>recalling the musl libc.so dynamic loader segfaulting (didn't bisect yet if there was any older tcc version that was stable)

<aggi>last tcc release tag for 0.9.27 is from december 2017, and if 0.9.28 was official anytime, it probably contains severe bugs

<aggi>i will try something else, pulling latest git HEAD of tcc, if something got repaired since march 2023

<aggi>i don't know, i could branch at a last known-good commit, to verify the complete i486-tcc-linux-musl.iso with

<aggi>but i am almost certain, since it seems noone else extensively tested tcc against linux-2.4 nor the (complete) system-profile that i got

<aggi>i doubt anyone else could nor would pick that up, because as said, it's 2.5years of commits to bisect/track

<aggi>stikonas_: anyway, i don't know if and whom to coordinate with, and it's blocking a release of mine with a mentioned fork/branch of tcc necessary

<aggi>and if i do that, i fear it is a potential dead-end, because i may not succeed tracking all those changes

<aggi>in a way, forking tcc is a bigger concern than maintaining a linux-2.4 branch (that i am planning to)

<aggi>and i do not feel comfortable with the idea, tcc mob branch is destabilized meanwhile bootstrapping of entire GNU/FOSS relies upon it

<stikonas_>no, I don't think anybody really maintains linux-2.4

<stikonas_>anyway, it's not like we depend on tcc mob for bootstrapping GNU/FOSS

<stikonas_>tcc 0.9.27 works too

<stikonas_>mob is only needed on riscv64

<stikonas>but that's because riscv64 is fairly new and was not present in tcc 0.9.27

<stikonas>anyway, for bootstrapping GNU/FOSS, one mostly needs C99 compiler

<stikonas>at the moment we mainly have tcc cause that was kind of the only compiler that was easy to bootstrap

<aggi>yes, that's what I keep in mind too, riscv64 that is based upon on an otherwise destabilized mob branch

<aggi>stikonas: i am less concerned about linux-2.4 than the fact i see no realistic chance to compile any later kernel version with tcc (or any other alternative toolchain such as cproc/qbe)

<stikonas>welll, that's cause everybody is developing linux with gcc

<stikonas>even clang can't easily compiler linux kernel

<stikonas>and clang is far more advanced C compiler then tcc or any alternative such as cproc/qbe

<aggi>ok, i will fork/block at a last-known working tcc-version, keep it x86-only, and live with it

<aggi>i've noticed though, there's some activity for bootstrapping riscv64, no clue how that's accomplished in practice, since they got neither a stable tcc nor kernel version for it yet

<stikonas>riscv64 work mostly focussed on userspace bootstrapping

<stikonas>so none of the kernel stuff for now

<stikonas>as for userspace, it is now possible to go from hex0 to GCC

<aggi>allright, then they'll have to fix it on the mob branch of theirs

<stikonas>though it's not very well scripted yet

<aggi>stikonas: i know, i tried myself to compile gcc and binutils with tcc, and it worked

<stikonas>well, on riscv64 there is a complication

<stikonas>that new GCC that has riscv64 support is written in C++

<stikonas>but ekaitz backported riscv64 support to GCC 4.6.4

<aggi>and the riscv64-tcc resides on a destabilized/broken branch

<stikonas>it's not broken for riscv64...

<stikonas>well, it can't build linux-2.4 maybe

<aggi>if you ignore kernel and various other linking issues it might have

<stikonas>but it's not like it supports riscv64 anyway

<aggi>too musl libc.so dynamic loader segfaulted, just as said, i didn't bisect this one yet

<stikonas>yeah, I briefly observed libc.so segfaults when working on live-bootstrap

<stikonas>but since we had an option of static linking, I didn't investigate more

<stikonas>and by the time we really need dynamic linking (e.g. python)

<aggi>ok

<stikonas>we have new enough binutils and gcc

<stikonas>so it doesn't block anything on live-bootstrap

<stikonas>it migth be nice to understand that segfault

<stikonas>but I don't think live-bootstrap itself would change the way it links

<aggi>i think tcc itself is very important, to keep that stable, reliable etc.

<aggi>which intersects with both, (minor) issues for live-bootstrap, and more severe issues with linux-2.4 (however that's related to "kernel bootstrapping", i will salvage a known-good state of tccboot)

<aggi>but ok, i will fork/block at a known-good tcc-version, and those may repair tcc who had broken it, and may need it for riscv64 - i can't

<aggi>stikonas: thanks for synchronizing reasoning about it

<stikonas>well, see what works for you and what you like to spend you time on

<stikonas>I think most people here find tcc source code itself a bit hard to work with

<aggi>both linux-2.4 and i486-tcc-linux-musl.iso were a decent test setup for tcc itself

<stikonas>oh for sure you tested more packages with tcc than most people

<stikonas>I was just trying to say, only work on it, if you find interesting

<stikonas>s/find/find it/

<aggi>that's how i will do it: stabilize what i got (since recently that's a linux-2.4 kernel), for a _complete_ distribution, converge and re-integrate this with bootstrappable

<aggi>then release it, as a stable(!) baseline

IRC channel logs

2024-11-11.log