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
