IRC channel logs
2023-04-06.log
back to list of logs
<aggi>obviously tccboot-loader and JIT compilation alter something linking/section/memory-layout related <aggi>including issues with linux/Documentation/exception.txt ex_table location, and/or memory-mappings <aggi>anyway, i am close to giving up on this; <aggi>because, i consider all this symptomatic for more principle issues involved <aggi>meaning, i am not willing to rely upon compilers/linkers/kernels which i couldn't reliably identify memory-layout/mappings with <aggi>as a consequence, this rules out: linux, gcc/binutils, since recently tcc-toolchain too, and Fiwix too required a patch to tcc-compiler concerning this <aggi>and i am not willing to touch llvm/clang either, since it's blocked against the no-c++ policy, besides other reasons (LoC of it etc) <oriansj>so you are going to end up making your own linker or have to leverage a non-standard one like mescc-tools <aggi>oriansj: i haven't got an insight into the work of yours, although i kept various TODO notes linked to your repos already <aggi>the reasoning here was, to rely upon bootstrappable established the chain-of-trust arriving at tcc-toolchain: which i intended to use as the _only_ system compiler/linker/assembler for entire kernel/userspace <oriansj>the M3 work was originally to produce all of the functionality of TCC as separate tools to enable easy replacement <oriansj>but the work from M2-Planet to mes.c and from mescc to TCC got done first and so it got shelved. <aggi>the acceptance-testing i did recently, with tcc-tooclhain, covered kernel-compilation; with the mentioned outcome <aggi>however, for several other reasons, Fiwix is highly relevant; but, i intend to develop on and use the system itself, instead of it being an intermediate bootstrapping phase <aggi>meaning, the idea with linux-2.4/tcc, was a production-ready kernel with decent hardware-support <aggi>i refrained from Fiwix, because hardware-support is limited, no offense intended at all <aggi>and the other problem, was the weird patching of tcc to support fiwix compilation with <aggi>oriansj: could mescc compiler/linker emit a fiwix kernel image? <aggi>and, besides, an assembler may too be missing... <aggi>oriansj: i don't know, what M2/M3 contain and are capable of <aggi>to my understanding, those are used as intermediate utilities, to bootstrap GNU-toolchain (which i am not willing to) <aggi>currenlty, there is no way around tcc-toolchain, and with this I failed recently, to compile kernel AoT <oriansj>aggi: simple and predictable compilation of C code; the assembly of the generated M1 assembly output and linking of the hex2 object files <aggi>oriansj: impressive. yet probably doesn't suffice for linux-2.x or fiwix? anyway, fyi, i sent a mail to bellard, and put you in bcc <aggi>ok. got no insight yet, how much efforts it is; and what's the more reasonable approach <aggi>oriansj: in any case, a linux-2.x/fiwix type kernel is required, and neither pass with tcc or mescc currently, without raising fundemental questions <aggi>that's the bootstrappable path, simplified: mescc->tcc->gcc/binutils->kernel/userspace; while the alternative mescc->tcc->kernel/userspace are blocked at tcc failing with kernel-2.x <oriansj>aggi: well that is the nice thing about a working path today, it gives you a target to hit tomorrow from a different direction. <aggi>oriansj: fyi, manged to create a somewhat working tccboot-loader (just changed to CC/LD/AS=tcc-i386 instead of the default gcc, and it launches now) <aggi>that's probably awesome, because with this i can re-produce and cover various test-cases, including a template to hack together a custom bootloader known to work, if it does <aggi>hooking into a latest version of tcc-0.9.27 too may need some refactoring, however, it's worth the effort now <gforce_de1977>aggi: thanks for not getting lost and writing a mail to mr. bellard - it would be bad to not ask questions <aggi>well, the AoT kernel image still crashes; at least now i potentiall can diff/bisect why that is <aggi>and, as an alternative, if i could not untangle this, then optionally i can rewrite tccboot a little, to load and execute a pre-compiled kernel.img <aggi>anyway, this was really important steps, because a chain-of-trust against the software supply chain can be re-established now, without gnu-toolchain involved <aggi>and, if linux-2.4 is finalized with some userspace, this too should be capable to bootstrap the whole GNU with tcc, with a fully capable system and decent hardware support which linux-2.4 got <aggi>anyway, i got another dozen of test-cases to launch in the next days, so i'll shut up and hack this <aggi>maybe Bellard got one or another hint too, which would be nice <avih>aggi: ok, so ignore that ;) <muurkha>aggi: it'd be great if he took an interest in the project <rickmasters>Mikaku: not sure if you're around but I may have a clue on the disk failures. <rickmasters>Mikaku: I got a "Memory exhausted" error from tar in a place that commonly would hang. <rickmasters>Mikaku: Its the first time I've seen that. Maybe the disk subsystem uses more memory and we're running out. <rickmasters>And most of the time something goes haywire in the kernel but in this one case it just happened to error out properly. <Mikaku>rickmasters: the message 'memory exhausted' seems to come from a user program, not by the kernel. In that case kernel should also show its own 'out of memory' message <rickmasters>Mikaku: Well kmalloc prints nothing if it returns 0 so I'm wondering what I will see if I add a printk in that case. I'm testing that now. <Mikaku>rickmasters: I think your branch of the kernel doesn't cover the changes in get_free_page() and reclaim_buffers() I did recently <rickmasters>Mikaku: I couldn't test with that due to the Issue I just filed but if the fix works I can start testing the latest code. <Mikaku>rickmasters: I'm just reading the issue #28 <rickmasters>Mikaku: re #28: so using sizeof(struct dirent) in readdir seems to work but just changing the kmalloc back to PAGE_SIZE is probably better. <Mikaku>rickmasters: ack, let's revert 58ca771 then <rickmasters>Mikaku: I don't see any kmalloc failures associated with the build fails.