IRC channel logs
2024-06-09.log
back to list of logs
<matrix_bridge><cosinusoidally> iirc it might have been a more general 2.4 kernel thing. Again my memory is hazy, but I think I also tried running stage0 under an old slackware installer (probably something like 10.2). I think I used slackware as the installer just drops you into a bash shell and can easily partition/format/mount disks. <aggi>i reviewed and bundled another test-setup for this again, cross-compiling tccboot on BUILDHOST=arm with i386-tcc-0.9.22 <aggi>with a little patching i arrived at this: <aggi>tcc: undefined symbol 'memcpy' <aggi>tcc: undefined symbol '__builtin_memcmp' <aggi>there's no linkage against BUILDHOST, only libtcc.o and tcc.o emitted from the cross-compiler for use by tccboot <aggi>so i a may merely have to provide those two symbols, and then see <aggi>later tcc-versions since >=0.9.25 are complicated, because they were re-structured internally and further multiple object files must be linked into tccboot then <aggi>and later tcc-versions require more libc symbols which aren't available without some more hacks, which who knows what went wrong when i tested it <stikonas>oh, apparently riscv32 and riscv64 checksum in stage0-posix git are broken after the last commit... <vagrantc>with mes 0.26.1 i *think* an XPASS triggered a failure to build on debian amd64 (a.k.a. x86_64) <vagrantc>do not really understand the difference between XPASS and FAIL ... eXpected to PASS ? that was my understanding with XFAIL ... <vagrantc>^[[0;31mXPASS^[[m: lib/tests/scaffold/a0-call-trunc-int.c <stikonas>I haven't treid tets on x86_64 there but mes still can't properly bootstrap tcc on x86_64 <stikonas>the good news is that for some reasonit seems to work quite a bit better <stikonas>tcc-mes doesn't immediately crash and can compile some very simple files <stikonas>could be, I just don't remember what testsuite runs... <vagrantc>on i386/x86 i think it does the full thing ... <stikonas>but yeah, given that tcc-mes is still somewhat miscompiled, we do know that it's buggy... <vagrantc>but i suspect it is using not well tested codepaths anymore <stikonas>probably, x86_64 just appeared very recently in mes, I think in 0.25 <vagrantc>i've been building x86_64 for a long time <stikonas>too many things were happening recently with mes <vagrantc>basically does ./configure && make && make install && make test .... but i386 and armhf pass --with-bootstrap where i think it does build mes from mescc <vagrantc>yeah, it ends up with mes-gcc everywhere and mes-mescc on armhf and i386 ... although armhf has been failing to build since 0.25 <vagrantc>well, figured i'd take the new point release for a spin :) <vagrantc>not entirely sure about maintaining mes in Debian at this point ... maybe it shakes out some bugs but is probably not terribly useful <vagrantc>it was fun to produce a bit-for-bit identical mes on a few different systems a while back <stikonas>yeah, but that was before stage0 was connected to mes <stikonas>so using diverse compilation was particularly important <vagrantc>it's been exciting to see all those links in the chain fill out over time :) <matrix_bridge><cosinusoidally> I'm guessing here, but it could maybe be a bug that has been fixed so an XFAIL should be removed. <vagrantc>that was on a local build ... we'll see if the CI pipeline fails in the same way eventually hopefully :) <vagrantc>yeah, will test with it removed from xfail ... :) <vagrantc>yup, removing lib/tests/scaffold/a0-call-trunc-int.c from xfail allowed it to build on x86_64 <janneke>okay, 90-signal never worked with mescc; moving to xfail <janneke>probably an artifact of --with-bootstrap disabling 90-* and a0-* tests :-( <stikonas>well, but report is less contraversial :) <janneke>haven't seen (any discussion of) this patch <stikonas>well, it's to enable to rebuild nyacc without using pre-built psyntax.pp in mes <janneke>mwette has been very helpful and considerate to our bootstrapping effort <stikonas>but the author of that patch is well known :) <stikonas>I should first check if it applies cleanly to master <stikonas>janneke: by the way, I've tested tcc-mes on x86_64 a bit more, it can build some other simple files, but nothing more complex <stikonas>I think I've successfully built all lib/ctype/*.c stuff and most of the lib/stub/*.c (with the notable exception of realpath.c) <aggi>managed to re-compile tccboot, yet with CC=i386-tcc instead of x86-gcc ... it's probably broken still <aggi>ACTION has to take a deep breath before booting the test.iso <aggi>the project-maps remained closed for more than a year, until getting back to this <stikonas>yeah, it looks like x86_64 tcc bootstrap is just one or two bugs away <janneke>have you looked at mescc' xfail list for x86_64 recently? <janneke>there could be a clue lurking, dunno <oriansj>aggi: the root binary problem only has 1 solution: provided by a trusted interface. (either you trust the interface for hand toggling/typing in your root or you trust the interface loading in the root from trusted storage [punched paper tape/floppy/etc]) <oriansj>solving the bios/firmware problem ultimately will require a trusted system somewhere (even if it is just a EEPROM on a breadboard with toggle switches) <oriansj>Then all that will remain is the trusted lithography problem (might be able to solve it with inkjet printers) and then finally the trusted physical reality problem (Once nanoscale assemblers are involved, I have no idea how to work around them compromising things from the inside during or after production) <matrix_bridge><cosinusoidally> I do sometimes wonder about the openness of the PC platform. The amd64 base ISA is now more than 20 years old. Wouldn't all of the patents have expired by now? I'm sure Intel/AMD would come after anyone who tried to create an unlicensed open amd64 chip, but is there anything that would actually prevent someone from doing so? <oriansj>well patents only have a very limited lifetime; copyright protection of the instruction set is perhaps a bigger issue. <Googulator>ISA copyright would fall under the same rules as the Java APIs <Googulator>basically "de jure copyrightable, but de facto not, since any copying for purposes of compatibility (why else would anyone copy an API?) is fair use" <stikonas>Googulator: have you tried qemu kernel bootstrap recently? <stikonas>not yet sure if it's a regression or already broken... <Googulator>last time I did qemu or bare metal was right before Configurator <stikonas>it seems to be stuck in a builder-hex0->...->reboot->builder-hex0 kernel <stikonas>I'll have to retest before my changes... <stikonas>though I still need to collect tcc checksum on riscv64... <stikonas>Googulator: looks like it's my upgrade commit that breaks something...