IRC channel logs
2026-05-26.log
back to list of logs
<roconnor>xentrac: I was thinking more like basement lithography a la youtube channels @projectsinflight and @Dr.Semiconductor <roconnor>Apparently when you build a fab in your shed you get to 100k subscribers quick. <stabbles>Hi all, I'm looking to do bootstrap tcc using GNU mes, entirely with x86_64. I noticed that Guix uses 32-bit binaries. Has anyone done this before? If I'm sticking to the same versions as Guix w/ x86, I'm hitting `unexpected size:42` during the first tcc build, and the CCLD step seems to be hanging using 4GB of memory. When I try the latest GNU mes <stabbles>I'm getting a segfault, even with what I think are compatible stage0-posix / nyacc. <janneke>stabbles: a native x86_64 bootstrap is being worked on <janneke>it might be that nixos found some clever way to do it, i'm unsure <janneke>we're planning to have a native x86_64 bootstrap available in a couple of months <stabbles>Oh, good to know, then I won't spend too much time on it now. What needs to be done to make that work? (fyi, I'm not particularly familiar with anything below tcc in the bootstrap chain :) ) <janneke>mostly compile.scm work, lotsa work ;) <janneke>any particular reason you cannot/do not want to/ use 32bit for stage0->tcc? <janneke>other than, yeah, we all want that:) <stabbles>That I've managed to do, which is very cool already :D thanks for all the work! The idea was to be able to bootstrap GCC+glibc in a directory of choice on any existing distro, without root access or user namespaces. I believe certain distros now disabled support for 32-bit ELF files <janneke>stabbles: that makes sense, and thanks! <janneke>stabbles: what distro/project are you working on? <stabbles>The Spack package manager. I recently added support for lightweight sandboxing with Linux Landlock, and that allows me to make just a handful of system executables available, like `/bin/sh`, coreutils, sed/awk/grep. And that's enough to kick off the stage0 -> mes -> tcc chain, etc. <wolfdog>is this the right place to ask questions about live-bootstrap? I wanted to know how well trodden is the kernel bootstrap path in it <wolfdog>I've been experiencing a lot of flakiness with the early bootstrap process (mainly Fiwix) with multiple cores and I wanted to know if this is something someone else has experienced <roconnor>Now I need to start my own version of Ben Lynn's Compiler Quest <roconnor>Also there is no garbage collector yet and that will probably eventually be needed. <xentrac>it's been a lot of years since I last wrote a combinator graph reduction interpreter. Beatrice and I were still married <xentrac>I wrote it in JS, so it got a lot faster when Chrome came out <roconnor>My RVE variant is so much slower that the RVI variant. I knew it would be slower but even this exceeded my expectations. Things will need to be revisited when I write a GC. <xentrac>does your graph-reduction virtual machine need more than 16 registers? <xentrac>wolfdog: I think this is absolutely the right place to ask, and if I knew the answer, I would answer. hopefully someone more knowledgeable will (janneke? oriansj?) <roconnor>xentrac: I have two versions of "libf0", one that uses extra saved registers and one that doesn't. <roconnor>The one that doesn't saves global variables into memory instead. <matrix_bridge><Jeremiah Orians> It has been transversed a few times but different hardware can bring problems that haven’t been resolved yet and honestly might not be easy to debug as hardware manufacturers don’t care about us. <janneke>wolfdog: for live-bootstrap i think you need stikonas (or fossy?) <stikonas>wolfdog: are you running it on BIOS system or UEFI emulating BIOS? <wolfdog>so far adding `-cpu=host,-x2apic` to the QEMU invocation seems to help with the flakiness, but this is on another machine, since I'm also testing on another machine while I let another invocation of lb to finish (on single-core) <stikonas>hmm, a bit strange that there were no reports of this before but I guess ounds reasonable <stikonas>that something in cpu propagates to qemu environment and causes problem <wolfdog>the one report i can find that is similar to what im going through is github.com/fosslinux/live-bootstrap/issues/430 <wolfdog>i haven't let it run for 5 days, but it matches what i see with Fiwix stuck after the device tree printing with 100% CPU <stikonas>in 5 days you can probably run it witout kvm... <stikonas>and I guess that protects against most polution from host kernel/cpu <Mikaku>wolfdog: looks like a problem of an oversized initrd image <wolfdog>Mikaku: how can I troubleshoot that? <Mikaku>well the first step is using the QEMU monitor and run 'info registers', then check the address of EIP to get an idea of what the kernel is doing