IRC channel logs
2025-02-09.log
back to list of logs
<stikonas>fossy: I think I've solved my qemu-riscv64 issue (random crashes): I've rebuilt QEMU without LTO <stikonas>RROR:../accel/tcg/cpu-exec.c:534:cpu_exec_longjmp_cleanup: assertion failed: (cpu == current_cpu) <stikonas>anyway, it works a bit better than before... <fossy>so maybe in part some kind of LTO bug? <matrix_bridge><Andrius Štikonas> anyway, I had only 1 crash now and maybe 10 good runs <matrix_bridge><Andrius Štikonas> Instead of 80% stage0-posix runs crashing before <ludocode>Quick question, why does live-bootstrap stick with such an old version of TinyCC and the Linux kernel? Is it because TinyCC doesn't do releases anymore and Linux 4.14 is the last version TinyCC 0.9.27 can compile? <ludocode>I just tested mob TinyCC with Linux 6.13.2. I made a wrapper that defines __GNUC__ and friends, disabled a pair of version checking scripts in the kernel, did a `make tinyconfig` and compiled it just fine <aggi>ludocode: any linux >2.4 does not compile without the presence of gcc/binutils and/or llvm/clang <aggi>to be precise for neither x86 nor amd64 <aggi>ludocode: how did you solve the problem of the absent support for 'gcc -S' equivalent with tinycc? <aggi>i am almost certain your test-case instead of tinycc merely picked gnu compiler and assembler when it should not have <aggi>ludocode: for linking kernel, tinycc does not support linker-scripts, how got that solved with your test-case? <ludocode>I don't know. I just typed `make` and it worked. I suppose it probably used gas instead of tinycc for the assembly bits ¯\_(ツ)_/¯ <ludocode>Yeah, looks like it also used GCC to compile the C. Well that didn't work at all. <stikonas>it does not know how to convert source code into assembly <ludocode>Is -S support the only thing missing? For linker scripts, tcc can just compile latest binutils right? <ludocode>For -S, is there an open source disassembler in C that could be used? Could make a wrapper script that builds with tcc then runs the disassembler on the output <stikonas>I don't know if it can compilre the latest binutils.../ <stikonas>but reasonably new binutils should be fine <stikonas>at least we can build binutils 2.30 with tcc 0.9.27 <stikonas>ludocode: well, the obvious open source disassembler is objdump... <stikonas>it's just one more step to get to GCC anyway... <ludocode>tcc 0.9.27 has serious miscompilation problems. A couple years ago I spent days debugging a bug caused by tinycc. Once I figured it out, I tried reporting it but the answer was basically "It's fixed in mob, we don't do releases, nobody cares about 0.9.27" <stikonas>yeah, it's annoying that they don't do releases... <ludocode>I'm mostly just thinking out loud here, I know this isn't really productive, but mostly I'm trying to figure out how to bootstrap latest Linux without relying on a) C++ and b) out-of-date software <stikonas>well, latest linux needs new enough GCC anyway <ludocode>(also it's at least two steps to GCC, the latest kernels require 5.1, so you'd need to build GCC 4.7 and then GCC 5.1 at the very least, and then you're well into C++ land) <stikonas>although personally I don't mind C++ once it is bootstrapped <ludocode>Yeah, but right now there's no way to bootstrap it without relying on old/obsolete versions of software <stikonas>well, cause we don't have any C++ compilers written in C besides GCC 4.x <stikonas>other than that, you don't need to rely too much on obsolete versions <ludocode>There are several problems with relying on obsolete versions of GCC. For one, does GCC 4.7 have a RISC-V backend? I'm pretty sure it doesn't, that means bootstrapping latest GCC on RISC-V would require an emulator for some other architecture <ludocode>For another, most places consider it a serious security risk to use out-of-date software. In my day job we're not allowed to use or ship any software that is no longer supported by upstream. <ludocode>I'm getting ready to bootstrap a kernel with Onramp (intending to do Onramp -> TinyCC mob -> Fiwix.) It will probably take me the better part of this year, but I'm starting to think about next steps after that (i.e. getting to Linux), and I'd like to try to make it all work with the latest versions of everything <aggi>i've rebased and tested some (not all) grsecurity things onto linux-2.4 for the sake of it <aggi>a relevant disadvantage of keeping a linux2 api/abi, that needs a fork of musl-libc, and extensive patching into rather many builds <aggi>i think i got most if not all of this done since last christmas/new-year nightshifts <aggi>but yeah, neither linux2.4 nor fiwix got risc-v support <stikonas>I've used it and was able to get to GCC 9 or so <aggi>except kernel bootstrap? <stikonas>well, we haven't attempted kernel bootstrap yet <stikonas>there is no point of doing kernel bootstrap before you have userspace bootstrap working <aggi>that's the question, at which stage fiwix/linux are a runtime dependency for bootstrapping process itself <stikonas>ludocode: in my work we are not allowed to use any softare that is supported by upstream :). Plenty of people are still on RHEL7... <stikonas>well, RHE7 still has extended support I guess but it's still from 2014... <ludocode>If you're on RHEL then your work is probably paying for support, otherwise you'd be using CentOS or Rocky <aggi>ok, question: the risc-v gcc bootstrap wouldn't need any linux runtime-abi for any of the involved userspace development utilities? <stikonas>well, yes, you need either running native risc-v machine with Linux kernel or some non-riscv other machine and run qemu. Nobody really develops on pen and paper anymore... <aggi>well, seems some bootstrapping issues got (mostly) solved for x86 that can't be with risc-v yet <stikonas>where you can do development, then bake CD or bootable USB <stikonas>if you just have x86 BIOS machine with no software and no access to any other machine <stikonas>you just won't be able to get sources into the form that machine understands <stikonas>e.g. there isn't something like front panel on PDP-8 <stikonas>that allows you to toggle some values into memory <aggi>i was referring to the absent risc-v support with fiwix <aggi>otherwise, yes, this is what my head is spinning around for a little while, some non-trivial circular dependencies and volatile, lets call it software supply chains <aggi>simplified speaking, what's missing is the entire 16bit realm, and bridging the gap towards 32bit from there <stikonas>well, yes, fiwix doesn't have riscv support <aggi>which i would consider far less critical, because a 32bit posix development host can cross-compile towards almost any target <stikonas>well, but other arches are making some progress <aggi>the relevant x86bit 32bit host however lost it's integration path from 16bit (with both hardware and software supply chains) <aggi>disagree, because free/open hardware development is feasible with 16bit systems, including deployment of development utilities etc <stikonas>just as you don't need 32-bits if you have 64-bit stuff working. It's just that we have bugs in some steps (mostly mescc I guess) <aggi>32bit free/open hardware development? doubt it <aggi>ludocode: i think the onrampvm of yours is brilliant; i've had no time to play with it though <ludocode>Thanks. It still needs at least a year of work before it's useful though <lanodan>Wow pineapple one is quite interesting <aggi>stikonas: nice, but i doubt the required development utilities for any 32bit system would be "bootstrappable" (avoid circular dependencies etc) <aggi>there is free/open 32bit hardware, which is amazing, yes, but it doesn't provide missing pieces some 16bit breadboard computer could <aggi>i am saying could, because, in practice, 16bit stuff got abandoned mostly, and i don't see a realistic chance to salvage the relevant parts <aggi>for example, fuzixos got ported to 16bit systems, but it relied upon SDCC, that again is written in c++ itself <aggi>as a consequence, some opcodes/assembly punched into a paper strip to load some program into the altair-8800 was the type of thing to begin with <aggi>however, this one is hidden inside some safe of <aggi>naturally, with 16bit system, BIOS routines got separated from the operating system - which wouldn't be necessary to do, if there was some _standard_ hardware <aggi>FreeDOS itself isn't bootstrappable, but a type of DOS and a c-compiler provided just what was needed then, to transition towards 32bit <stikonas>well, FreeDOS was open source for a while too <stikonas>what I meant is that even before MSDOS source was published <aggi>FreeDOS itself seems not bootstrappable however, and it's alot of effort <aggi>but, free/open hardware is much easier to implement with 16bit; most of this can be done with pencil and paper and a breadboard <aggi>and _this_ would break the circular dependency surrouding development utilities for hardware, bootloader, bios etc <aggi>16bit system could, 32bit can't, simplified speaking <aggi>but Intel themselves began phasing out their 16bit systems... most prominent the problem surrounding UEFI/csm <aggi>so Intel could not boot their own system-integration stuff they got, even when that was some proprietary DOS, it wouldn't boot <aggi>and, in practice, there's many interesting 16bit systems remaining to play with free/open hardware, assembler etc. <aggi>but the transition towards 32bit systems isn't covered <stikonas>oriansj: any chance you could run your fuzzer on M2-Planet? <stikonas>we have merged quite a bit of stuff recently... <oriansj>stikonas: yeah, it'll take a little bit to shake out all the bugs but I'll get it started <oriansj>aggi: I agree that to make a robust long term bootstrap root we will need 16bit software. Ideally on hardware we can build ourselves with minimal firmware/microcode. <oriansj>but honestly, I am toying with the idea of designing hardware and just making a batch and giving the parts away to anyone who mants them. <oriansj>stikonas: wow, found segfaults already. Will start fixing <Googulator>Regarding Pineapple ONE, one phrase is really alarming: "has a 512 kB program memory and 512 kB RAM" <Googulator>the amounts are not the problem, but rather the fact that it has "program memory" and "RAM" - sounds like (unmodified) Harvard architecture, inherently useless for bootstrapping <lanodan>Or it's to mean something like storage on like NVRAM/EEPROM.