Hi, referring back to some mailing list noise of mine i've made some progress with kernel and spotted another test-case which could be helpful to isolate a potential bug in tcc when compiling/linking linux-tcc kernel: https://codeberg.org/aggi/linux-tcc
First, for practical reasons with a linux-tcc system, you might notice a little more driver code and other updates were applied (latest r8169 gigabit ethernet tested ok, ax8872 usb-ethernet fully stabilized, stable unionfs support, and so far the workaround in conjunction with the reported kernel panic with sata/ahci is stable when dumping hundreds of GiB disk i/o with it while self-hosting compilation of a tinycc driven distribution; - see 2026-01-05 below for the sata/ahci related test-case) Recently i've patched/backported some high speed random number generator and, then again, noticed sporadic kernel panics out of nowhere (killing interrupt handler, with keyboard keystrokes, without going into detail.) Now, and this could be relevant to tinycc-devel, dont' ask me how i arrived at this in desperate need for some workaround again, see the following patch; when i've added some NOPs into empty function dummies the kernel panics in conjunction with the re-implemented random_scrandom.c/scrandom.c vanished: /* * linux-2.4.37/drivers/char/random_scrandom.c to replace random.c * https://codeberg.org/aggi/linux-tcc/commit/139f6824b57fb186ab8fcdb624f801194e1dda15 */ void add_keyboard_randomness(unsigned char scancode) { + + int nop = 0; } Which raises a suspicion, maybe tinycc does some dead-code elimination and/or adding some NOP into empty function dummies affects symbols linked into kernel? I haven't the slightest clue again, but i could confirm with some certainty this prevents mentioned linux-tcc kernel panics. This too could be a side-effect or some timing-related issue, which is merely hit by coincidence when compiling/linking with tcc. You may not want to waste time with this test case if none of the tinycc-devs got an idea related to this. Anyway, i've deployed the tinycc-driven distribution into production as my main development host regardless, and entire userspace seems sufficiently stable (mutt, irc, lighttpd, ssh, nfs, tor-proxy, can't test all 500 builds individually, it's up and running for days and weeks). Which means, other than the somewhat annoying linux-tcc kernel bugs confirmed for being related to compilation/linking with tinycc the whole thing is approaching a release-tag made for upload. Furthermore, with the recent extensive runtime testing having passed for a complete i586-tinycc-linux-musl.iso it may not be too problematic publishing a devdrop release ISO, for easier re-production (although the development setup isn't trivial to get involved with in case any tinycc developer would want to, because as documented at http://tinyfront.mooo.com/docs.html this project involved a few more concerns not exclusive to tinycc; besides the web-site already is hosted atop linux-tcc/tinycc-driven distribution with most recent software version backported; the high-speed embedded crypto stack and PRNG is discussed in the projects section if you're interested) Otherwise i've not made any progress when contacting various employers, universities etc. which complicates the situation. Feedback appreciated. Michael On 2026-01-05 17:50, Michael Ackermann via Tinycc-devel wrote: > Greetings, > > beginning with the good news again, with a powerful nightly-build setup moving > back to linux-tcc kernel hacking i could successfully test sata/ahci on > several > different machines, with decent performance (~250MiB/s, nice), in comparison > to > usb2/flash which already was stable, PATA/IDE is working too of cause but > rarely > available with modern hardware, so recently i've > - added all known PCI_VENDOR_ID for SATA support with common ahci.c to > linux-tcc > - and re-tested the driver rebase/backport for AX8872 usb-ethernet asix.c > > The kernel fork of linux-2.4 for support with tinycc is updated to latest HEAD > at https://codeberg/org/aggi/linux-tcc > > Nightly test builds done with: > $ i386-tcc --version > tcc version 0.9.28rc 2025-12-17 HEAD@34eed88a* (i386 Linux) > > Which brings me to an issue discovered recently with tcc driven distribution > nightly-builds when compiling/linking kernel, which again isn't trivial to > report and even more difficult to isolate any root cause this time: > 1) either compiling and linking kernel binary in a single pass > -> kernel PANIC; runtime bug caused by tcc > -> see comments in Kbuild.sh:241 compilelink_kernel function call with tcc > 2) or, first compiling all objects with tcc indvidually and then linking them > thereafter into linux-tcc kernel image with tcc in a separate phase > -> NO kernel panic, weird, because first i considered a bug in ahci.c > itself > -> see Kbuild.sh:243 compile_kernel and link_kernel functions, mostly > trivial > 3) doing either to reconfirm with gcc and custom Kbuild.sh which isn't > affected > at all hence irelevant, it merely isolated this issue related to linking > kernel with tcc variant 1) > > To reproduce: > in case of 1) tcc compilelink_kernel in a single-pass produces mis-compiled > /mis-linked kernel, which triggers kernel-panics with ahci.c with dd disk i/o. > As a workaround, in case of 2) this problem does NOT occur, although kernel is > compiled/linked with the exact(!) same configuration except doing compiling > and > linking separately. Weird. So, that's the good news, i got a workaround for > linux-tcc kernel which does not panic with sata/ahci, even with some bug in > tcc > i guess. Mentioned test-setup reliably reproduces the kernel-panics or avoids > them by the compile/link variant chosen with tcc _only_, so i am almost > certain > it's not some bug in linux-2.4/ahci.c > > Question, do variant 1)/2) alter the order of objects/symbols internally? > Kbuild.sh scripting does not change the order of objects. I did notice before > the order of objects/symbols linked into kernel can affect kernel-init > sequence, > but this didn't trigger kernel panic and i could re-order objects manually > (see kfiles-2.4.DEBUG). Option for -fgnu89-inline didn't have any effect > either. > It seems tcc linkink variant 1) probably introduces some memory corruption > this time. No clue why. > > Furthermore it's interesting the recent extensive run-time testing with a > self-hosting compile of a complete tinycc-driven distribution was done with > a linux-tcc kernel variant (1), and the problems, luckily, were not triggered > elsewhere in kernel. But i've just recently tested full ahci support. > Thats probably symptomatic, tcc/linking doing something which seems to cause > memory corruptions causing kernel panics i can't isolate. > This too reminds me of issues with bash5.static erratic _runtime_ behaviour > and > rolling back to bash4.static, merely another work-around to make it work > initially. As said it's alpha-testing devdrop builds, and this report could > provide a decisive hint to some error root cause with tinycc linking. > > I'll proceed with debugging the backported ax8872 usb-ethernet dongle, whose > instability with large network-packets seems unrelated to the current problem, > because instability occurs with all linking variants with either gcc or tcc so > it must be a bug inside driver code unrelated to tcc. > Networking inside virtualbox or some older thinkpad t40 with other ethernet > drivers is reliable already, but i can't nor won't backport dozens of drivers. > Hence availability of some common cheapo usb-ethernet dongle is desirable, > and one last major technical blocker remaining for some release made. > > In case you wanted to test linux-tcc kernel with some real hardware yourself: > - i'm using a cheap HP T620 for bare metal, those are available for ~30Euros > - i got another Fujitsu Futro S930 (a newer AMD model with PSP), working too > - overall any real-mode bootable x86 hardware since CONFIG_M586TSC or later > should suffice with usb1/2 cdrom and flash memory, pata/ide, sata/ahci, > (optional) vesa-framebuffer (requires manual vga=980 parameter) supported > - and of cause Virtualbox or Qemu, for sake of simplicity i'm using vbox still > because i couldn't yet compile/link qemu with tinycc itself anyway and don't > want to rely upon virtualization/emulators exclusively (which was a main > reason why linux-2.4 was chosen since it passes with tcc and got sufficient > hardware support) > - some latest N97 type intel system re-confirming linux-tcc and hardware > support > with it would be intersting, seems a desirable target for a linux-tcc driven > system; if anyone could spare any let me know, it should work > - some recent AMD Ryzen (PSP) driven system could be releveant for testing of > basic hardware support with linux-tcc too > > I may upload some minified devdrop ISOs and/or initrds > (see Kbuild.sh INITRD variable), the initrd/romfs from Bellard's original > tccboot.iso can be used too, which contains dd, ifconfig, ping; with > dd if=<disc> of=/dev/null bs=1M count=1024 to reproduce the sata/ahci related > kernel-panic. linux-tcc-2.4/devfs creates disk device nodes in /dev/discs/* ; > Should be almost trivial to test tcc with Kbuild.sh yourself if you wished. > Just as said i don't want to drag tinycc-devel into kernel and/or > distro maintenance tasks, and want to make it as simple as possible to get > anyone on board with a tinycc-driven GNUish/POSIX distribution gradually. > So the Kbuild.sh related tcc bug related to linking might be a decent starting > point. > > Michael > > On 2025-12-20 13:26, Michael Ackermann via Tinycc-devel wrote: > > Took a little while, made a complete test-run with latest tinycc HEAD > > against > > > > > > On 2025-12-16 14:07, Michael Ackermann via Tinycc-devel wrote: > > > > > > Concerning nightly builds of a tinycc-driven distribtion i'll open another > > > thread soon. > > > > > > ttyl, > > > Michael > > > > > > On 2025-12-16 13:43, Herman ten Brugge via Tinycc-devel wrote: > > > > Op 16-12-2025 om 11:46 schreef Michael Ackermann: > > > > > > > > Current tcc is at: > > > > tcc version 0.9.28rc 2025-12-15 mob@8569427 (i386 Linux) > > > > We made some changes this year in this area so please try latest > > > > version. > > > > Herman > > > > > > > > References > > > > > > > > 1. http://tinyfront.mooo.com/docs.html > > --
signature.asc
Description: Digital signature
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
