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
signature.asc
Description: Digital signature
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
