should have taken a nap instead, since i did i could re-establish the test-cases for re-producibility, that was/is 1) kernel panics with a re-implemented kernel core random.c/scrandom.c - this one was reproducible again, only a little less reliable - i've deactivated/reverted the overriden random.c to it's default to rule out that one - with extensive review i could not spot any potential error in random_scrandom.c, it only provides a quality random stream at >1GiB/s easily, with non-predictable entropy too, it's only 1000x faster than default /dev/random /dev/urandom so maybe this triggers some timing issue - ( see git log if you're interested https://codeberg.org/aggi/linux-tcc/commit/d17485b5630be2b30ff1b6e5f5f4390eae61c3b6 ) - ( for that matter the loopdev cipher had proven reliable and robust and it is derieved from the same mathematical rationale, that one does not trigger kernel panics although it's implemented against another kernel-internal api https://codeberg.org/aggi/linux-tcc/commit/ede4ba1022e571cca61f35cf639b48b5d972c141) 2) the sata/ahci.c related bug is triggered reliably - however, outside a virtual-machine on bare-metal hardware instead - and with this i can too reliably re-confirm it's caused with the compilation/linking variant chosen, meaning if i386-tcc compiles/links linux-tcc in a single pass then kernel panics when disc i/o on sata/ahci disk - when objects are compiled individually first and then linked in a separate linking pass then disc i/o does NOT trigger kernel panics -> so this issue is persistent still indicating some flaw regardless of any optimization variant, dead-code added into dummy function calls etc.
Those two test cases may or may not be related to each other, other than it's kernel-panics involved. And the sata/ahci.c one seems more plausible to isolate this to i386-tcc specifics. Anyway, at least i got some linux-tcc kernel build with the workarounds mentioned, to keep the tinycc driven distribution up and running reliably. On 2026-02-05 15:49, Michael Ackermann via Tinycc-devel wrote: > Instead of taking a nap i've re-compiled and tested linux-tcc kernel a dozen > times. Strangely, now i've had difficulties re-producing kernel panics with > either the ahci.c/sata test case and/or the [sc]random.c hack (meanwhile i had > rebooted the virtual machine host system that i've tested kernel builds with) > I could pull some hairs out over this. And suspect it could be some > timing-critical and/or symbol-ordering issue which was merely hit by > coincidence > with tcc. At least, i've arrived at some stable linux-tcc kernel again which > does not panic with any compilation/linking variant. > > However i did notice one peculiarity, i386-tcc -U__OPTIMIZE__ -O0 reports > missing symbols with final kernel linking stage which -O1 -D__OPTIMIZE__ did > NOT > //tcc: error: undefined symbol 'htonl' > //tcc: error: undefined symbol 'ntohl' > //tcc: error: undefined symbol 'ntohs' > //tcc: error: undefined symbol 'htons' > > Hence for -O0 those functions were added to > linux-2.4.37/arch/i386/lib/dummy_syms.c > > Latest kernel sources are git-pushed, and i'll leave it as is with -O0 for > now. > Long story short, i am NOT yet sure if this was the hint to the real root > cause. > > Regards > Michael > > On 2026-02-05 09:15, Michael Ackermann wrote: > > Hi, > > > > @noneofyourbusiness thanks for the quick response and hints provided. > > > > > I'm wondering how you phrase those requests > > > > I'm trying to remain polite and technically precise with any inquiry. > > When coping with HR and universities i'm referring to the tiny test site at > > http://tinyfront.mooo.com and a little german language prosa for a covering > > letter. I'm applying as system integrator, that's what i can do, coping with > > hundreds of patches, several deployment variants and build system for > > hundreds > > of packages, kernel libc. > > > > > d.g.a.f about that apart from surviving another day at work > > > > Sigh, i've got no intent for any offense nor getting anyone into trouble. > > As you > > might guess i'm having sufficient trouble on my own already. > > > > Next to the technical questions at hand... > > > > > > + int nop = 0; > > > they're not NOPs, adding a variable there affects the stack > > > > OK, it's some dead code, same with the sata/ahci related test-case there's > > merely been some workaround but no final bug-fix. It's just good enough to > > keep > > a fully tinycc driven distribution up and running now. > > > > > this doesn't fix the bug, some issue on the stack remains > > > > yes, but the workaround reliably prevents mentioned kernel panics and could > > help > > with isolating issues of a tinycc compiled/linked kernel further. I am not > > sure > > yet myself if it's merely some timing related side-effect hit by > > coincidence. > > > > > if you want to learn about this > > > > I am. I've had 16bit real-mode asm hacking on my wishlist for a little while > > already (see tinyfront/docs.html assembler section why that is) > > > > > interesting, please keep us updated > > > > i'll try my best as long as possible. > > > > With regards to debugging, it's some kernel image instead of some small > > test.c > > which complicates this. > > > > > - tcc has an 'optimize' flag > > > > Thanks for the reminder. Before debugging down to asm level, next i'll play > > with > > this one, since i got two test cases now which i can reliably reproduce > > issues > > with. Tired, need sleep. > > > > ttyl. > > > > Michael > > > > On 2026-02-05 08:40, noneofyourbusiness via Tinycc-devel wrote: > > > This is a multipart message in MIME format. > > > > > > > > Michael Ackermann via Tinycc-devel <[email protected]> wrote: > > > > 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: > > > > > > this doesn't fix the bug, some issue on the stack remains > > > > > > > > > > > /* > > > > * 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 > > > > > > no > > > > > > > adding some NOP into empty function dummies affects symbols linked into > > > > kernel? > > > > > > they're not NOPs, adding a variable there affects the stack > > > adding a "int nop = 0;" is misleading - this changes the stack pointer > > > compared to what it would have been > > > > > > > I haven't the slightest clue again, but i could confirm with some > > > > certainty > > > > > > if you want to learn about this, feel free to use some > > > reverse-engineering tools for your aid - see attachments > > > just looking at the C code isn't going to give you the information that > > > you require for learning about this > > > > > > > Anyway, i've deployed the tinycc-driven distribution into production as > > > > my main development host regardless, and entire userspace seems > > > > sufficiently > > > > > > interesting, please keep us updated > > > > > > > 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. > > > > > > good > > > > > > > Otherwise i've not made any progress when contacting various employers, > > > > universities etc. which complicates the situation. > > > > > > I'm wondering how you phrase those requests, perhaps you should package > > > what you're selling a little differently according to your audience (i.e. > > > someone who d.g.a.f about that apart from surviving another day at work) > > > > > > -- > > > > > > more details on attachments: > > > - the DWARF format is more usable than STABS with radare2 and rizin > > > - it seems like the tcc DWARF output is not quite there yet for r2 - > > > those source code annotations are misleading > > > - tcc has an 'optimize' flag, which has an effect when its value is > > > greater than 0 - i.e. -O0 disables them, -Os, -O1, -O2 lead to the same > > > effect > > > - feel free to confirm the lack of "dead code elimination" by disabling > > > the debug output option and enabling the tiny bit of optimization that is > > > available > > > > > > -- > Michael Ackermann > Mail mailto:[email protected] > > pub 4096R/72CAC8E1 2014-05-08 Michael Ackermann <[email protected]> > uid Michael Ackermann <[email protected]> > uid Michael Ackermann <[email protected]> > sub 4096R/F5492994 2014-05-08 > _______________________________________________ > Tinycc-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/tinycc-devel -- Michael Ackermann Mail mailto:[email protected] -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFNrjggBEADkI7X9PeN9Kxy+EsSLgYDsxxnT2A/l3YpM31XrjAMDABmMYdsY JU6uV8u1qMR+QSwUw/Jomy1mqEwMfrmHMQ3Ym/9vzpVrmptH9wtmJBqxpHDIlApu iYHByQb2mleRGv3qbV2ul+5w7X4xg8sIk/I+S0Wp9gShEC8xRre0CD9agVGfznsV aOEpoknY/gLH25UyVtarzmJx/SepXpHkKgsNxYF3Q+DhKvBWZqxov/I0rQavdflB wsGsH+kfiRXW9mBS2aH3lc0ihOMTOLDZzT4NVTa4zHT+5R8PjS8apnnxoR3U7SLp 8Oanf7aNf7ZYaDAg1s6/ulJairSalE9Df5lo7xEv6RtXLZxOA69ss04/u/OBH2wK yZy3eXijVReGk/eqPly2CxAKN8rI2GvXXvZwwtxfiOWu3fDjM7ipET2YgZJ5MGDf 9glGSfHn9xy0lnQ26PeEFNnwpIb8gKg0ipVEkREDPTILXXNmhyjEFITgkWki6wt+ 3QXNE+v/hORjYzV4Y02gr7K3Marr0blVjoqJ1KJkBZ+c/nmOovjKq758czGVz5ZU 0+Ed99w1uAucbewlJmtHZocm5IpK/URBV9Kcu/rG9Wor+Da/qme8K3jbH3qSN8oT o1/CXTr0xntCs8fkYRcQa5lByOl8XvyyzGH5FL9mnsA/D/Mcr42fvLxH0QARAQAB tC5NaWNoYWVsIEFja2VybWFubiA8YWNrZXJtYW5uLmpvYnNAb3V0bG9vay5jb20+ iQI3BBMBCgAhAhsDAh4BAheABQsJCAcDBRUKCQgLBRYCAwEABQJcj6vfAAoJEC3F Lq5yysjh2B0QAKXd0sL0EBM7cKquiIKqPlzmAYROP5oaxsm7HaI1FiDFirqV3mN3 cTl1xEiPLKC8jnqZrjup9qx6dySawpovjXowXaDt8a/64KnoaUaEzX8Uu1BvZHeZ /eBsPcYZfFFUfDP6t08RNdPpVITI4otRYkc41mIuKHIA6NvYGETOC72ITpXHDdlC nbutX3EluZRVrckj7pssWvQE1f6GvsQbb87ih+h6AfVkdkKk2qKeKjkyYLinMJx0 Vea98pRE51swMnEqVcp6ihx3l/9LAJJISQVEmxUQFJsJXJreoaUlk4dmiEv+Pduv IlHfXWaqUCoK+ZY3UHpujr8cdH60AzdzCREeEujbWyI6kMT+r2dg5tiwxbPs3N1N V2ixowsCK7HRXYhGLo0mJcs1vasS1Czq8vb2ovtm2r0Ruld1g+wZHaB6Q1cGllkX uCNEAn1eftGqvHIm1NdR3I5lD7Isu/53eYvEq5+AugNj8Jfy4gZiY8GC6v8e/BhU tFaoFo7gN8xscJh/hmtAMYy4qNBDhAFUsXlDbEmqEG1HCz1EMGyXJthxto8QH35p l63bkbdlkkHZc0kfwSX4Mkg/AXl1Jbtr/h8qJDEzlIm1SPsYAQvkTsGQ8FGPWf6m XNd1BxtdkD05+IHrG4/k933UVfkhnKq7gVnYzSPSf1nENYVjZeOoKQnntC1NaWNo YWVsIEFja2VybWFubiA8bWljaGFlbC5hY2tlcm1hbm5AZ214Lm5ldD6JAjcEEwEK ACECGwMCHgECF4AFCwkIBwMFFQoJCAsFFgIDAQAFAlyPq98ACgkQLcUurnLKyOE7 5hAAukDSpkFQA38kem8Fxh2qOpyVef07rMsxfZzGV3Khb5dJ6VmPM8tl1SWIsS0W BLQMFMpDRDxM4dGyEdaUGzc5V3L+IVQmrddyOrLsy2rgfgp26RKKuA6VaElVMGNw mU+XTLCJTewzOnMq06T7+/wv/pLo1Tf2R7e69evOxy1fXBciUA63kyxu/nO/SHTQ jtQd5bVoMPYHAgxu80dHPOsKOT5OLKtQj/LegYMqEg/gKlVRFJq46pRd9JAQ3Jxe v/CTUXl89xCWLmMqeMijwWfbysNFfj741kfRohmvVgz0atx9CePQcq3GYMQ8/ND3 EdJMusHESfqxIv1W+VGMIbic4+tzAGImCX+/LmAuiCVJeK5DI6E88AL9H+ei7Md4 jvvmBUx4FJYlJik/4e6XidgVgytxHnC8xcv1T2y7oMit/1az2KJ/kL2QDIKEOaCR 8HeZ6S/sqOp7juXz/tDJ1DfNSMsuDtY0S5VRtAmEOboq63BGRJiC9oKZvM0Hdv0D XEBP4QmFW5YNNu9W2f/ySKQ6TVzanv9OI6IMnh5XfNdMf7CXJv3pDzS4+pOJ+aNo Ebmx5vSaP+0NEHJHwqry0A8tlZAVojzCyq+oRQgzCnJu56chLDPQtZmXjsIS33KF Ht+HzDPaPK9bGaQpOF0/mQM/8b2BIX9UOgUSySBDaV6Wrc20LE1pY2hhZWwgQWNr ZXJtYW5uIDxtaWNoYWVsLmFja2VybWFubkBnbXguZGU+iQI3BBMBCgAhAhsDAh4B AheABQsJCAcDBRUKCQgLBRYCAwEABQJcj6vfAAoJEC3FLq5yysjh7vkP/1hqF4XW X2xQ3FBofPZQMH7jFM1YiTf64E/S5ByRMNYsFqKYDBRX+xGaoOfXD5kTuIQBU+BM yFG8KpS/586OhcDboRDvS6vqV2vFW0AXLAOLErfPsVa7jLvfzH7TVqmmVxQ0MmLQ XRgun297lGIxBp3WHhgJpAHxcZubh60CA7MbXV+UMOtiFGcYLaum9HNuz6oi/PtC Ldo9+pLawQExvz+QtT5IbbFjTHE/UxT5FA4lSNtOJdETAYq/FJcTiFpn5Ep7wnFr yE5D+rkKR3O64yOJl47q2JFkPzELh6VNAlWaZfs/mJOsUurkX2Nekw9YCsNHlGqR 1i/CJO1jqjGJOCT2iBbC5Z3ElN2WK5FDMOf6DiwTtuPmEdJ8sil64Axgds81fO1c +mq32TnRq2WcMYbi1ZBaOUGcjr0wPqnrK2WIC2VqkmiNfVYE6HXIQbxDWH1W86wT uMrTeBNxuv7Kv6QzH5B41F43elVSo0cvuD58A9Hr+fGswPnPuh6unBecoSJQVRFL L+1mwJV0pJbwxkaFu5sONUP/Csoopj2M/TTOclsIFoKxEitXeHzT8m+kSZLNrC+c QAhCcK5tfYgp5EBjlodOiDNqpAUwTQ2rz/ppN2McDZM/0ORR7xWaN/wKs0hiVVyc rg+8zEe7VnmNWl/dQH0wFk9jb60diKSqvna0uQINBFNrjggBEADZQloirgt7FbhL O0AaLFb3UmXOCzMxbkiDR+3sXk91KEufJTIK7IbIK1vm0kB+KRH0ubgGGzb+YILu OZdengLXVL34AoKpeknzzp5wpGhsFdN36W+5MsmlVf6cTzxcavT5pCDEfvIb128v Zw2xzODuFS+Dr4nRGlFnP+mzSR7bRufkhZ7nVcg1nYYwbLeUSRdRxyBQ9fvkw83L gvcEsBOASmZ6uI0okxAnruOHOlNkXOmjJSaBlElD+rxYR8A7cvrq4B/L44BZOXXn jDTwLJ6uXeGE31aO2xbGBPzCWRKpiK+pIPF9o2DLAlE3joi5bIUDPUD9xm2HMkLi jwKEqsTgeDcjNigKFgfBvmkUKtreU1PNzm97IoGrfe9W+N3PfZeCrSsrEUlNCy19 1i5oQbaNIVR5nNk2+yfqwGW01S7uQrLO/lvWUk1AJ9fCaC3Zq1tHNpiVN89FeeLa lRF7+TUyKyt4RdUdqYTZEthBuZ0CxV7mvPmCGK2bIi23OyD509L3m7hKKysPtwZx ycSoe4GRB6S7WdINiPtt1Zwv5TkMIQUDoBvuq+AkHiNTdOhheeMavsMu2AHgQ/vU p/396DzQwWozSlUtb/R+X+cSvc67t2+/2EfBZI9ghoms0gTsvVanZZqIBNQuy98h Tua1dnzaA9Tu1FI6EEi/suC4nAVh4wARAQABiQIfBBgBCgAJAhsMBQJcj6vnAAoJ EC3FLq5yysjhCDUQAKDnMaz4i2HKZbtXvjoXrJRK3mBxCRNj7tkmrXSOVqFdJN7q CPoekjpV8M588FBTRQr6Q3BzFp4vAWnhKYfflgzprsTNRrLNLQWIo9LQXpD9y98Z r8qAeGPFMSLTe7ttu2Kntslx9X17IziJuYU8GIQUO212iRAmSUdhXITb4v19fFBe 6aTxw1r7SpvdWASKwcVk7UEdnflzOnXJXLtqUy5Zi7rKMfkLeo2UbEGg9c+dbVak No/jrZQwUMTGc7OTl3v1euZ0qstySoKNBDtwsURXKf3GLGIcagY66MrMYCKc3YC8 hdcJTWntvaNLzpekE75WeIspjjFK4WSqFumNs9SBglyJN96+9nlrBcQYBJOWXv+o QqwZSihhbLYLVUQZ3lzTM4PHnHqQ7bQIo0t16kMWCA6E1brnfOv3QpEHuJceO5Qz kkOPcdWSAM30X0pZ9ubGUCOaN7K1/0y40C32aXf1lWjOCPZh1c8qC0AYh8TDXA43 ovALG37LJs/SUCIckVVPSJw9E1zHpTioNHzhwNfS1fmfRLFeQqkJemH85zWImilx c7EzyM6+TdQU4Mt9tCSQ4f0MhZI3x1m8pspM214wcqSIQkIAPWTi4vXKc9vKNK9z D4v2mCoz552mctyPsnj4tGgcju3YnqXtbs529h2IORqtXw7PRIYP1OIOMbgZ =Sza0 -----END PGP PUBLIC KEY BLOCK-----
signature.asc
Description: Digital signature
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
