IRC channel logs

<stikonas>they are suprisingly capable but once you start pushing the liimits, lots of things break

<stikonas>and hard to fix since we don't have an abstract syntax tree

<matrix_bridge><Andrius Štikonas> gtker: there is probably an issue with your AArch64 defines, I'm bisecting

<matrix_bridge><Andrius Štikonas> but it causes qemu to error out with Illegal instruction

<matrix_bridge><Andrius Štikonas> hmm, it's aarch64: Convert all files to GAS style defines

<matrix_bridge><Andrius Štikonas> so maybe some of the new defines don't match the old ones....

<matrix_bridge><gtker> Stikonas: I'll take a look later today. I think it'll be easiest to just compile a program with all the functions and then compare hex2 output

<fossy>aggi: I know about nothing about MES-replacement, sorry

<fossy>well, at least about the current state of it, i am aware of its existance

<matrix_bridge><cosinusoidally> Just checked out the latest version of https://github.com/FransFaase/MES-replacement . It's capable of building bit identical "i386" copies of "tcc-0.9.26" and "tcc-0.9.27" from live-bootstrap. I was able to reproduce by running "cd src", "make" (which errors out due to something amd64 related, but still builds all the required i386 stuff successfully). I then ran "cd .." followed by "./task3.sh".

<matrix_bridge><cosinusoidally> But I'm not sure what the plan is for the stuff in "src". Currently it needs gcc to build them. I assume they will be ported to the M2 dialect at some point.

<matrix_bridge><cosinusoidally> tcc is built in a rootfs under a chroot. The only initial executable code in the rootfs appears to be "hex0-seed" and "kaem-optional-seed" (but they don't seem to be the upstream versions). Other than that there seems to be some "hex0" and "M1" files that were built by the "make" step.

<matrix_bridge><cosinusoidally> Took about 10 mins to build tcc on my system, but I was in a VM and I think a decent chunk of that time was due to io (according to the "time" command 6 minute were spent in syscalls).

<aggi>ok, good to know. i did not use make files but the kaem scripting

<aggi>and the Makefile contains a line which does: ./run.sh gcc $(basename $@)

<aggi>which, probably, is appropriate for some testing done with MES-replacement (the T-diagrams and documentation)

<aggi>i want to re-integrate the stack_c/tcc_cc into stage0

<aggi>yesterday i reviewed the entire regular proceeding up until M2-Mesoplanet being available, and currently wrapped the chroot/rootfs preparation into some dedicated scripting instead of live-bootstrap

<aggi>i suspect M2/M2-Mesoplanet can compile stack_c/tcc_c sources, which is what i'll have a look at today

<aggi>then i have noticed some other minor mis-match with stage0-posix-x86: ./x86/bin/sha256sum -c ./x86/x86.answers

<aggi>it's a complete mis-match, but i pulled latest HEAD with all repositories here which seems the reason for this

<aggi>i think, with MES-replacement the regular stage0-posix-x86 is done at Phase-6/M2 being available

<aggi>initially i'll try to compile stack_c/tcc_c with M2-Mesoplanet and then reconfirm with M2

<aggi>by coincidence it's too Phase-6 up until when i could track each M2Libc-file individually for what's hit by an include <>

<aggi>and that's something i do not fully grasp yet, if MES-replacement hooks into after Phase-6 (and may not be earlier since tcc_cc.c ans stack_c.c ust be compiled)

<aggi>why then it restarts the whole proceeding at hex0

<aggi>i think Frans intended to track the entire call-graph with his T-diagrams

<aggi>i don't see an option to spawn stack_c/tcc_c any earlier than Phase-4/5

<aggi>and for practical reasons M2-Mesoplanet should be good enough, except for the fact i could not track all M2libc include <> anymore at that stage

<aggi>then of cause, if cc_x86/M2/M2-Mesoplanet do not succeed with compiling stack_c.elf/tcc_cc.elf the whole MES-replacement approach is blocked indefinitely and i'll proceed with mes-cc instead

<aggi>cosinusoidally: just for the record since you considered this done in "about 10 mins"; at Phase-6/7.../23 of stage0-posix-x86 there is no make utility available nor gcc

<aggi>and it is stage0 where tcc_cc/stack_c belong into

<deesix>aggi (off-topic) I think you want "of course" instead of "or cause".

<deesix>*of

<aggi>unable to read file: <malloc.h>

<aggi>Aborting hard!

<aggi>this seems to indicate stack_c.c had not been integrated with stage0-posix before (except if i missed something else)

<aggi>and this is the type of details i would want to be aware of in advance

<aggi>./src/stack_c.c:1118:we can't expand a null token: }

<aggi>./x86/bin/M2-Mesoplanet --operating-system Linux --architecture x86 -f ./src/stack_c.c -o ./x86/bin/stack_c

<aggi>./x86/bin/M2-Mesoplanet --operating-system Linux --architecture x86 -f ./src/tcc_cc.c -o ./x86/bin/tcc_cc

<aggi>/tmp/M2-Mesoplanet-000000:2510:Can not use non-defined type in object

<aggi>maybe that's both trivial fixes, but it's not trivial to debug

<aggi>and i do see something else, which adds to the confusion... M2-Mesoplanet does pull/include non-x86 *.h/*.c from M2libc, maybe there's some #ifdefs which exclude those

<aggi>i could try with M2 instead of M2-Mesoplanet next

<aggi>so, in tcc_cc.c that is: FILE* _f; // error

<aggi>sigh,... typedef

<aggi>although it seems M2-Planet/cc_core.c does handle typedef

<aggi>now I have to think for a moment, that's probably more than "10 mins" time, how to proceed

<aggi>could be M2 was used by Frans instead of M2-Mesoplanet... seems there's a clash with stdlib.c used

<aggi>in any case, if stack_c.c/tcc_cc.c were compiled within stage0 before, it probably wasn't M2-Mesoplanet which did it

<aggi>for that matter i rather compiled stack_c/tcc_cc with M2 anyway, because then this could hook into stage0/Phase-6 where it belongs

<aggi>something else which is hitting my stomach currently, cheap instant coffee, german government budget doesn't allow for any other, ludicrous

<aggi>i've contacted several dozen "startup" supporters here again, affiliated with various universities and employers

<aggi>but that's something really "off-topic" in here what i think about the business habits of these

<matrix_bridge><gtker> stikonas: I can't find any difference between the defines in the commit and the ones in the commit before. What exactly are you compiling? If you can give me the ".hex2" files from both I can take a look

<matrix_bridge><gtker> stikonas: Pushed M2libc update on M2-Planet

<aggi>sigh... found something, trivial, with regards to M2 C-dialect (wich i've hit before in kaem too)

<aggi>but i can assure: *.c|h sources bundled with MES-replacement currently may not pass compilation with M2/M2-Mesoplanet as is

<gabif>hmm, does mescc -c produce both .o and .s ?

<gabif>is that hex2+M1 or binary+M1?

<aggi>long story short: a few more hacks and tweaks, M2/M2-Mesoplanet CONNOT compile stack_c.c

<aggi>*CANNOT; so i may skip tcc_cc.c and with it MES-replacement alltogether for now, please correct me if i'm wrong

<aggi>i may draw another conclusion from this review already (since i've not looked at stage0-posix before)

<aggi>bootstrappable.org did a great job documenting all those issues, and hacked a somewhat plausible system-integration beginning with their stage0-seeds

<aggi>but I would consider the whole "bootstrapping" issue unresolved still - even when livebootstrap does emit some gcc-10.x with a bootable linux5 whatever

<aggi>the real unresolved issue i see is rooted in stage0 still with M2 available and it's limitations

<aggi>i mean, bootstrappable deserved an order of merit almost for documenting all this, but it's unresolved still

<aggi>conceptually, my opinion, it should be the stage of M2 already with a sufficiently capable assembler/c-compiler/libc available to spawn, let's say, a BusyBox and Fiwix kernel with it

<aggi>instead re-compiling tinycc 9times total, plus another 4 re-compilations of gcc, this could be namecalled however you wish, but this does not solve bootstrapping where it must be

<aggi>the approach from Frans with MES-replacement, seems to be yet another approach to damage-control of what went wrong with bootstrapping

<aggi>for this, MES-replacement is good as it is, to document the whole thing with T-diagrams

<matrix_bridge><Andrius Štikonas> gtker: I just ran make test-aarch64, let me check what command was running

<matrix_bridge><Andrius Štikonas> ./AArch64/artifact/M2 --architecture aarch64 -f ./M2libc/aarch64/linux/bootstrap.c -f ./M2libc/bootstrap.c -f ./M2libc/bootstrappable.c -f ./mescc-tools/stringify.c -f ./mescc-tools/blood-elf.c --bootstrap-mode -o ./AArch64/artifact/blood-elf-0.M1

<matrix_bridge><Andrius Štikonas> I think that's the first binary that is built with M2-Planet

<matrix_bridge><Andrius Štikonas> gabif: that's hex2 and M1 in .o and .s files produced by mescc

<matrix_bridge><gtker> stikonas: I stage0-posix-aarch64?

<matrix_bridge><Andrius Štikonas> yes

<matrix_bridge><Andrius Štikonas> with master / main of Aarch64 and M2libc submodules

<stikonas>gtker: can you reproduce?

<matrix_bridge><gtker> Trying it out, just a sec

<stikonas>I only tried on qemu so far, don't want to risk on my real aarch64 box while I'm travelling this week

<stikonas>in case I crash it. Though kernel in theory should catch segfaults

<matrix_bridge><gtker> I'm getting an error that fputs isn't defined? Do I need to do anything other than check out stage0-posix at master and change M2libc/stage0-posix-aarch64?

<stikonas>gtker: yes, you need main branch of M2libc

<stikonas>that's due to your bootstrappable.c refactoring

<stikonas>where multiple aarch64 specific implementaitons were unified into a single file

<matrix_bridge><gtker> I had M2libc, but it seems stage0-posix-aarch64 local main was behind because I haven't pulled in forever

<matrix_bridge><Andrius Štikonas> oh, sorry tahat's master branch of stage0-posix-aarcht64 submodule

<matrix_bridge><Andrius Štikonas> pull in that

<matrix_bridge><Andrius Štikonas> yeah, I've fixed it there

<matrix_bridge><gtker> Also getting illegal instruction

<matrix_bridge><gtker> I'll investigate

<stikonas>gtker: hmm, that M1 file sitll have uppercase defines

<stikonas>maybe that's the reason

<matrix_bridge><gtker> That shouldn't change anything though?

<stikonas>oh yes, we haven't removed old ones...

<matrix_bridge><gtker> On "bd58905" I get illegal instruction, on "bd58905~1" I get "Unable to open for reading file: ./M2libc/bootstrap.c"

<stikonas>oh, that's because you need to undo aarch64 change

<stikonas>that adds bootstsrap.c to kaem scripts

<stikonas>that M2libc commit predates your bootstrap.c rework

<matrix_bridge><gtker> I ran M2-Planet on all the files that had changed in "bd58905" before and after the change and after running "M1" on them there were no changes. Could it be something else in stage0-posix-aarch64?

<stikonas>hmm, there wre no new commits on stage0-aarch64

<stikonas>except that kaem change

<matrix_bridge><gtker> Ah true,

<aggi>there's some simple shell CI-scripting without git-submodules since recently, but it's blocked having arrived at M2-Mesoplanet/x86-only with latest HEAD of all except M2libc

<aggi>and i can't yet nor won't use QEMU since it's backport to tinycc/os is blocked

<aggi>i've noticed another peculariaty, kaem cannot export ENV variables such as ARCH=x86|aarch64 for use inside kaem scripts interpreated by kaem

<matrix_bridge><gtker> stikonas: Looking at the diff of "M2-0.hex2" with pass/fail and it seems like the new defines aren't being expanded? Anywhere I can upload a diff quickly?

<matrix_bridge><gtker> Specifically read/write/open/close/brk/exit aren't expanded

<matrix_bridge><gtker> Which matches the platform specific functions in the new bootstrap.c

<aggi>and i would advice caution, to expand the current concept of live-bootstrap to other ARCH, since there's is one or another question remaining before doing so, conceptually

<matrix_bridge><gtker> (also matches the changed functions)

<matrix_bridge><gtker> stikonas: It seems the line "./AArch64/artifact/catm ./AArch64/artifact/M2-0.M1 ./AArch64/aarch64_defs.M1 ./AArch64/libc-core.M1 ./AArch64/artifact/M2.M1" uses the "aarch64_defs.M1" in stage0-posix-aarch64 rather than the M2libc one?

<matrix_bridge><gtker> Which doesn't have the new defines

<stikonas>oh oriansj had some reason to split them

<stikonas>if I remember correctly

<stikonas>hmm

<stikonas>I never fully saw the need, but I think the non-m2libc once are for cc_*

<stikonas>ok, thanks for root causing it

<stikonas>cc_* I guess uses far fewer defines?

<gabif>stikonas: thanks!

<stikonas>well, cc_aarch64 in this case...

<stikonas>gabif: you are welcome

<gabif>i believe there are 3 files with M1 defs (one more in mescc) that can be merged, but i guess merging them will slow things down

<gabif>or there is one more on aarch64?

<matrix_bridge><Andrius Štikonas> well, there is one in stage0-posix-$ARCH

<matrix_bridge><Andrius Štikonas> one in M2libc

<matrix_bridge><Andrius Štikonas> and possibly one or more in mes

<matrix_bridge><Andrius Štikonas> I think mes has a copy from M2libc for bootstrap from M2-Planet purpose and then another one with mescc defines

<matrix_bridge><Andrius Štikonas> (in case of riscv64 they are luckily identical, but that's not true for other arches)

<aggi>live-bootstrap probably needs an overhaul _before_ expanding towards other ARCH than x86, with a few hints given why that's the case

<gabif>one can argue that there should be one per arch

<aggi>and for ARCH=x86 itself there's many open questions remaining, with both HOW bootstrapping is accomplished, and WHAT is bootstrapped for an initial development host

<aggi>hi gabif

<gabif>i'm still talking about *_defs.M1

<gabif>aggi: hi

<aggi>well yes, in a way, there's some headroom for standardization with assembler macro syntax (language frontend variants) and hardware backends

<aggi>gabif: go ahead

<aggi>sorry then, currently i'm thinking if i would proceed with mes-cc at all (instead of tcc_cc/stack_c)

<aggi>because there's too many other, well, concerns, known in advance

<aggi>up until M2/M2-Mesoplanet i would consider it good-to-go for ARCH=x86, but not any further yet

<deesix>aggi, what hacks and tweaks are you talking about? Which intructions are you following? People said you need to match the submodules, for a start.

<deesix>aggi, vague (yet verbose) claims does not help.

<aggi>deesix: i already did outline a roadmap and proposals in recent days

<aggi>with issues such as, kexec-fiwix cannot be replaced with a make_bootable fiwix at that moment, which is merely symptomatic stemming from other root causes

<aggi>and, shrinking the whole dependency graph, by whichever means possible

<aggi>for that matter, that's what Frans documented with his MES-replacement and T-diagrams, it's gotten a little out of control

<deesix>aggi, my question is about what problems are you having with the live-bootstrap procedure, as is.

<aggi>i've already named MANY of these problems

<aggi>that status as is, is unacceptable

<aggi>it does solve many problems, yes, but it does not solve the "bootstrapping" issue itself

<deesix>No, you have not give details... only verbose and vague rants. Good luck with that.

<aggi>i've not begun ranting, although some issues deserved just that

<fossy>aggi: i have legitimately no idea what you mean, could you be way more concrete? I'm always willing to hear out ideas, but I cannot make any sense of your ideas here

<fossy>what is this "real unresolved issue"?

<fossy>"kexec-fiwix cannot be replaced with a make_bootable fiwix at that moment" -- what does this mean, and why is it a problem?

<fossy>what is the 'bootstrapping issue itself', if not what l-b solves?

<fossy>i feel like you are on a completely different page to everyone else with regards to what a successful bootstrap even is

<stikonas>indeed, most people here assume that bootstrapping is building at least somewhat modern system starting from the absolute minimum amount of binary seeds

<stikonas>it doesn't really have anything to do with specific language or tools used

<stikonas>and live-bootstrap running on top of Linux kernel achieves userspace bootstrap on x86 in a fully automated way. x86_64 / riscv64 versions are also fairly close but not really automated

<stikonas>but on x86 it just works

<fossy>right. and if you want to do a different boostrap, that isn't to a "somewhat modern system", that's all good, go for it! however, l-b's explicit goal is a modern Linux system

<deesix>Yeah, philosophical questions aside... if some step is not working while trying it, just say so, along with what you did.

<stikonas>as for lower level bootstraps, if you want to bootstrap a kernel, live-bootstrap integrated that rickmaster's buider-hex0 on BIOS systems. It can build modern Linux and hence almost any other kernel

<stikonas>yes, sometimes it happens that it doesn't work, usually some reproducibility issue, e.g. perhaps some date sneaked into manpage

<stikonas>and it stopped working, or some upstream tarball disappeared

<aggi>just as said, i consider the current bootstrapping approach up until M2/M2-Mesoplanet excellent work

IRC channel logs

2026-03-05.log