IRC channel logs
2024-06-26.log
back to list of logs
<stikonas>we probably should build bearssl early... <stikonas>oh, that is only used if savannah is down... <aggi>greetings... made a little progress bisecting tcc-versions/kernel-versions and related issues <aggi>last time when i moved the whole linux-2.4 bootstrapping setup onto slackware11 buildhost i could reproduce various test-cases with a kernel booting without crashes <aggi>however, wasn't satisfied what had caused the crashes before... and today i found a first hint which is a little concerning and seems to affect all kernel versions and tcc-versions i tested <aggi>meaning, moving onto slackware11 buildhost was merely a lucky hit <aggi>to summarize: tcc got issues linking linux-2.4 kernel (related to some FASTCALL macro, the dummy_syms.c introduced by bellard, see for yourself what was done on the original tccboot.iso) <aggi>those linking-issues seem unspecific to kernel, it's just those are triggered under specific circuumstances, which i am tracking down currently <aggi>for example, it makes a difference if (kernel) objects are compiled/linked in one step, or if compilation and linking are separated into two steps <aggi>the former seems to succeed, the later doesn't report any issue while linking, but kernel crashes regardless <aggi>which raises principle concerns over the status of tcc-toolchain, and relying upon it, for either kernel-bootstrapping, and, depending on QA criteria, too #bootstrappable itself <aggi>since someone recently reported a broken #bootstrappable release with an updated tcc-version involved <aggi>to me this seems a lucky hit and miss, not necessarily related to any specific tcc-version, but how symbols are resolved/linked etc. <aggi>because i had spotted merely a lucky hit, to reproduce tccboot and/or linux-kernel bootstrapping AoT <stikonas>well, I didn't catch it myself personally, just my run failed <Googulator>oriansj: can you enable plain HTTP access to files.bootstrap.world (or do you have it already)? <fossy>Googulator: yeah, it doesn't have it at the moment <civodul>i already noticed that virtiofs support relies on a separate Rust daemon <fossy>i think we are going to see a fair bit more of this direction <fossy>thankfully at least in my mind, qemu is a fairly user-facing application, rather than a core system thing that we care loads about in bootstrapping <fossy>qemu is already a large codebase with many indirect dependencies <lanodan>And by default has bios/uefi/… blobs included. <oriansj>Googulator: files.bootstrapping.world can be downloaded by any method you desire (I just need to set it up) (It exists to make your lives easier)