IRC channel logs
2023-03-30.log
back to list of logs
<aggi>the kernel crash when calling sti (set interrupt flag), seems merely a symptom of init_IRQ gone wrong some place before <aggi>and too, the delay calibration loop relies upon interrupts handled, which is why it was stuck at that <aggi>another question is, how tccboot.iso from Bellard october/2004 could have ever worked before, because with any tcc-version tested failed here, with different problems <gforce_de1977>aggi: have you compared the kernel-sources which tccboot uses with yours? I remember that i once also tried to replicate this but failed and gave up - so i wish you power! <aggi>gforce_de1977: yes, i used the exact same sources, compared with tccboot.iso; same order of compile/linking <aggi>it is not plausible nonetheless, as said, the timestamps do not match <aggi>tccboot.iso was released before relevant git-tags/commits were stamped; <aggi>it's just not obvious, which compiler-version bellard used (it probably wasn't the one which is included in tccboot, 0.9.21, because this version fails with the sources) <avih>aggi: re version mismatch, maybe he applied local patches, then created tccboot, then pushed these (or similar) changes to the tcc repo, so that teh equivalent tcc repo version is slightly later than tccboot? <aggi>avih: yes; however, i too checked 0.9.22 which appeared almost one year later than tccboot.iso, and errored too in i8259.c; which i can reproduce reliably <aggi>the principle problem remains, which sources/version of tcc-compiler did bellard use, year 2004? <avih>right. did you try to re-create tccboot (and boot successfully) using your sources? <aggi>avih: "tccboot" requires a definition; if you mean utilization of the bootloader - no, i didn't try yet <avih>maybe the difference is pre-compiled vs jit? <aggi>a moment ago, i tested various other: compiling with gcc, linking with tcc, and vice versa... <avih>(though it would still be interesting to see why that file is not compiled, or compiled without issue, in "jit mode") <aggi>i can narrow down the problem, to i8259.c, interrupt handling reliably <aggi>avih: yes, it is complicated however <avih>(i've never looked into tccboot) <aggi>avih: don't know yet. i skimmed the sources quickly only <avih>did you check whether tccboot processes than file? <avih>e.g. if you insert an obvious error in it, does tccboot still boot? <aggi>i only grabbed the /boot/tccargs file, to verify the source list, order of compilation/linking, and diffing this <avih>so the source list include this file? <aggi>i see, yes, tccboot bootloader, somehow, don't ask me how in detail, does a type of exec(tcc, tccargs)... <aggi>avih: yes, /boot/tccargs shows in which order files are compiled/linked by tcc, and too i diffed all those against the local tree, v2.4.26 - no differences <aggi>except, tcc-version, which itself is unknown <aggi>for the reasons mentioned <avih>and i guess you verified the diff is not in the CFLAGS in tccboot: -D__KERNEL__ -nostdinc -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__OPTIMIZE__ -fno-common <aggi>including various different kconfigs, including a one which matches config.tccboot 100% <aggi>too i tested two different kernel versions, the one from bellard, and 2.4.37.11 from seyko2, i diffed all source trees, verified all patches <aggi>and i think the problem is the following: <avih>i think your next step must be to recreate tccboot and see if you can get it going, and if yes, it would be easier to poinpoint diffs, right? <aggi>a combination of linking/c-preprocessing/asm issues, which causes a side-effect in init_irq failing (with or without apic support) <aggi>avih: ok; but this won't help, to identify why the non-JIT compilation/linking fails <avih>aggi: also, you should consider emailing bellard for clarifications/help if you just can't figure it out <avih>luckily, he's still around <aggi>besides, too, i refined/verified the build-system of this, which fully detangles from Kbuild; <avih>(afaik most recently he's been active with quickjs) <aggi>meaning, i would consider the scripting reliable, meaning only swapping CC/LD for either tcc or gcc ... gcc ok, tcc fail <aggi>avih: thanks for listening <aggi>anyway, i am thinking about something else, to hack gigatron ttl or Z80 instead of what i had seen in recent days <aggi>the tcc-compiler problem, indicates, that kernel-bootstrapping (simplified speaking), is broken for 20 years already <aggi>and, pardon, linux support for clang, doesn't change that fact <avih>i don't think you can say that, unless you're able to pinpoint the issue? <avih>that is, more specifically than you have already <aggi>i am saying this, because i can't pinpoint it reliably <aggi>i could only narrow down the problem, to the interrupt handling/init <aggi>and all else, is kept inside the logfiles <avih>right, but because you didn't find the actual problem, you can't rule out a tcc bug <aggi>it's a combination of several, issues, some of them, severe <aggi>tcc, is a sanity check, for those issues <aggi>and Bellard did showcase, it's possible <aggi>myself however, had to depart elsewere... z80 or gigatron or some DOS type asm hacking <avih>it might have worked due to luck someplace <avih>i.e. some bug which due to whatever combination of factors ended up seemingly working <aggi>i would be curious myself, if Bellard was confident in this, or why else he had abandoned this precious project, 20 years ago <avih>i think that's his modus operandi, create something to to some level of usefulness, then move on to something else and let others keep hacking at it <avih>you could similarly say he abandoned ffmpeg or qemu <aggi>there's another branch of this, -seyko2, which too fails here <avih>anyway, i recommend emailing him with summary/details of what you concluded so far. he might have something interesting to say