IRC channel logs
2024-01-21.log
back to list of logs
<stikonas>hmm, just retried building tcc-mes on x86_64 <stikonas>with one small mes patch tcc-mes shows some signs of life <stikonas>though building other things prints assert fail: mode == x86_64_mode_sse and segfaults <stikonas>strangely inserting one printf makes it work quite a bit better <stikonas>I was not able to build unified-libc.c in one go , but file by file it seems to build <stikonas>though it still crashes on trying to rebuilt tcc with itself <oriansj>musllll: if someone wants to do formal specifications and theorem proving, it'll probably improve the trust but until someone steps up to do it. It'll just remain on the nice to have list. <GoogulatorMobile>cosniusoidally: are you seeing your Fiwix trampoline freeze on a recent Intel CPU? <matrix_bridge><cosinusoidally> GoogulatorMobile: how recent is recent? I'm on an Ivy Bridge Intel CPU (circa 2012). I might have generated the init.img in a slightly odd way, I'm just trying again atm. <matrix_bridge><cosinusoidally> ah, my fork of live-bootstrap is not fully up to date with master in the main repo (my branch only has commits upto the 10th Jan). I might just be missing some fixes. <stikonas>janneke: yesterday I tested x86_64 mescc->tcc bootstrap and with seom patches got some promising signs of life from tcc-mes (though not complete bootstrap) <stikonas>though I think we discussed it at some point earlier <stikonas>and you said it starts failing some test <stikonas>might even be the same tests that is failing for vagrantc but I don't remember now <stikonas>anyway, with that patch applied tcc-mes can build crt1.c but crashes on most other things <janneke>(no, but it's in the same problem area) <stikonas>with another (even stranger patch) I can compile most of libc <stikonas>that other "hack" is inserting one printf statement in tcc:x86_64-gen.c... <stikonas>no idea why it makes segfault go away... <stikonas>I still wasn't able to build getopt.c or tcc.c <stikonas>anyway, for now I just have this change: <stikonas>- (wrap-as (as info 'long-signed-r)) ; huh, why not long-r? <stikonas>+ (wrap-as (as info 'long-r)) ; huh, why not long-r? <janneke>sure, do anything that works/seems to work <janneke>we're missing some aspect wrt compiling portable c code here <stikonas>I guess ./lib/tests/scaffold/17-compare-le.c ? <stikonas>well, I'll see how tests are doing and send the patch... <janneke>yes, i'd test all the 17-compare tests <janneke>ACTION was hoping we'd get to the bottom of this during the riscv64 port, but somehow we managed to wiggle past <stikonas>probably riscv backend was not using that thing <stikonas>in x86_64 this code was triggered when doing something like o("0x12345678") <stikonas>janneke: oh those tests are failing before my changes too on x86_64 <stikonas>unless I'm doing something wrong with my environment... <stikonas>well, I'll try to run x86 bootstrap with my change <stikonas>it's unlikely to be affected given that this is mostly 64-bit change <matrix_bridge><cosinusoidally> I'm no longer having issues with the builder-hex0 to fiwix trampoline. I think the issue was because I was using the bare metal init.img under qemu. This time around I'm using the --qemu flag. Seems ok with the latest version of builder-hex0. It's currently building guile so it has successfully built fiwix and Linux. <lrvick>Naming things is hard, but in my mini distro I have "stage0" as the stage0 triple build setup, the live-bootstrap setup as stage1, the cross compiler stack as stage2, and the whole rest of the distro that consists of all the final distributable trusted compilers for various languages as stage3. <lrvick>if reading that made you facepalm because I am wildly misrepresenting the common usages of "stages" in this universe, lmk <GoogulatorMobile>cosniusoidally: The bare metal img will output to VGA instead of serial console when Fiwix starts. <GoogulatorMobile>Before Fiwix, SeaBIOS is used for console output, which autoroutes between VGA and serial based on -nographic; Fiwix instead selects its console based on $BAREMETAL. <stikonas>janneke: thanks for merging the previous patch. I'm still testing (on riscv64) that mescc patch (long-signed-r -> long-r) that helps x86_64 but in the meantime I've started looking at the next problem <stikonas>but if I insert "mode;" on the next line things seems to work <stikonas>and I think the important extra line is movslq_%eax,%rax <janneke>stikonas: whut, how did you find that workaround? <stikonas>well, I wanted to debug stuff, so I wanted to check value of mode <janneke>it looks like "just a function call" apart from maybe the vtop dereference <stikonas>so first, I inserted printf("mode = %d\n", mode); <stikonas>so then I started looking for someting simpler <stikonas>anyway, perhaps the register had some rubbish there? <janneke>but, working code is always great, it often is a step towards understanding or finding the bug <stikonas>in the worst case we can add a workaroudn to tcc <stikonas>it would be much better to understand the root cause <stikonas>so we are probably missing some sign extension somewhere there <janneke>i've taken quite some pieces of code out of tcc as inspiration for the mescc test suite <stikonas>yeah, but I guess mostly from i386 file... <janneke>but that could work too; if you could isolate the call and find it to fail in a small test, that would be super helpful <stikonas>yeah, we do need a smaller reproducer... <stikonas>small reproducer is usually the next step <stikonas>at least that was often the case when ekaitz and me debugged riscv64... <stikonas>we are probably just a few bugs away from working bootstrap <stikonas>(not counting various other integration work that needs to be done) <stikonas>(for native x86_64 bootstrap to work on guix and live-bootstrap) <stikonas>well, tcc => gcc-4.6 shouldn't be too hard if you are willing to package musl <stikonas>and once gcc is built, we can easily build a fairly new glibc <stikonas>perhaps eventually meslibc can also include more functions <stikonas>well, it's probably harder on riscv64... <stikonas>we are still hitting various tcc bugs there <stikonas>but I think x86 and x86_64 should be simple <Googulator>This should fix boot on IDE and IDE-emulated SATA drives. <Googulator>Also, I made it much easier to pull in future builder-hex0 fixes; builder-hex0 is now a submodule linking to rickmasters' repo. (This will be useful when my next batch of changes, fixing USB flash drive boot, gets merged upstream.) <stikonas>janneke: still trying to figure out that tcc "mode" variable issue <stikonas>something more complicated is going on and so far I have no idea why adding "mode;" helps <stikonas>without it vtop->type.t & VT_BTYPE for some reason is evaluated to 9 and goes to VT_DOUBLE switch/case <stikonas>with it it is VT_VOID and goes to correct case statement