<pder>I guess I am still not clear how guix manages to get to gcc just using mes-libc? <pder>is it due to gash and other utilities written in scheme? <fossy>stikonas: I'll make a roadmap issue today I guess <stikonas>I guess gash has some utils to help with configure scripts that we are struggling <stikonas>basically guix goes directly to binutils and gcc from where we are... <stikonas>coreutils actually has regex.c and regex.h which flex needs <stikonas>although, regex on its own is not enough... <stikonas>guix even builds coreutils after gcc and glibc... <stikonas>but at least we seem to be reproducible for now <pder>I havent tried it yet, but I am curious if our tcc version can build later versions of tcc. <pder>It would be interesting to try using musl, but personally I think it would be better in the long run to add missing things to mes-libc and fix any bugs there, since its important to have that solid before building another toolchain <rain1>what about a meta bug tracker for bootstrapping in general to post and stay updated on questions like that? <stikonas>but yeah, either we need to expand mes libc or get musl <pder>True, but I think someone added musl support to a later version than 0.9.27 <pder>Actually the first commit related to musl I see is release_0_9_26-1030-g0ac29b53 <pder>Has uclibc been considered? <stikonas>(or if that doesn't work, then maybe extending mes-libc) <stikonas>in the very worse case, it might be possible to write makefile for gcc... <stikonas>musl probably got a bit easier now that we have bash and coreutils... <stikonas>so we don't need to write our own build system <stikonas>but there were still tcc problems when compiling musl <xentrac>I may have missed messages intended for me :( <stikonas>it's just literally adding it to COREUTILS in makefile <stikonas>argh, I think yes was the missing piece for manu configure scripts <fossy>because configure handwritten, no? <stikonas>but there are some problems last I checked (with busybox) <fossy>hooray the first piece of software that we can use a real buiild system for <stikonas>and there are some problems with some assembly files <fossy>stikonas: oh, i know what that is <fossy>the assembly thing is that tinycc (our one at least) dosen't have hex numbers <fossy>all hex numbers have to be converted to decimal in assembly <stikonas>you can try to look at those problems I had... <fossy>that's at least one issue, i ran into it with linux <fossy>also, what do you think about removing sources/ directory and downloading directly to tmp/? <deesix>"""xentrac did an amazing job with stone-knife FORTH but eventually opcodes still has to show up eventually.""" That was the msg with you nick. <stikonas>we can either patch source or get tcc snapshot... <fossy>it would mean that it would have to redownload each time tho <stikonas>fossy: a bit cheating, but I finally managed to use configure... <fossy>stikonas: i am still not a fan of mob <stikonas>yeah, we'll see, it's not too hard to patch statics out of source <fossy>i remember now, the weird syntax <stikonas>do we want to rebuild tar with makefile and getdata that we patched out? Or not worth it? <stikonas>it wouldn't really give us any benefits... <stikonas>but yacc is able to deal with tar's getdata.y <fossy>um, i don't really mind. i don't think it provides much of a benefit <fossy>hm, it might be worth for configure scripts though <fossy>i know autotools configure scripts are datesensitive <fossy>but i think it's just it has to be newer than a file in the tarball (and i think all our files are unix time 0) <fossy>yeah, everything is at Jan 1 1970 <stikonas>well, I check bash between 2 runs was identical <fossy>well if we extract the time, that's still reproducible <stikonas>by the way, we used some proper build system for something <Hagfish>in the Hacker News comments, someone even talks about bootstrapping gcc <OriansJ>I love the create a C compiler in assembly line, like they don't even realize that we have already done that to bootstrap M2-Planet <xentrac>the orange website is invariably full of highly-voted fools; you don't get highly-voted comments by waiting until after you've read through an entire article to post a comment about it ***mephista is now known as spicy_icecream
<gforce_d11977>fossy: can you maybe use 'mkimage' from uboot to convert your vmlinux to bzimage? <fossy>gforce_d11977: thanks for the pointer, i will def take a look <fossy>i am seeing that kexec can take an elf. but the elf dosen't work <fossy>so i might have better luck with bzimage <gforce_d11977>fossy: at least it's worth a try for fast conversion and if it succeeds, the tool is maybe not too hard to compile <fossy>it dosen't seem to make it into a bzimage, rahter a "u-boot image" <gforce_d11977>so you dont need any compression, but a bootable kernel (e.g. bootsect.o + setup.o + misc.o + piggy.o) <gforce_d11977>fossy: have you tried to build 'kexec' for userspace with the minimal toolset what live-bootstrap provides for now? <bauen1>pder: i'm using a stripped down version of musl with tinycc, but i've choosen some commit from mob, iirc because some minor features where added that made my life easier <bauen1>but i can't remember if it was just related to the kernel or also musl <bauen1>in any case building musl with tinycc is doable, but requires some adjusting due to unknown assembly opcodes <bauen1>actually i may have some patched musl code lying around for building most of the library for linux-x86_64, let me check <bauen1>weird, something keeps setting +x on musls libc, breaking my ci <bauen1>of course it doesn't happen locally, because that would be too boring <bauen1>looking at what tinycc commit i'm using for myunix fb1fb8219ccf4813d63edf8c40fddc756e0c60cc, there is: <bauen1>2f94390 musl: disable boundcheck tests <bauen1>245f6a0 stdarg: always have the __builtin_va_* available <bauen1>those three commits are probably important for building musl <bauen1>iirc with older versions there are some problems with double defines, and redefinitions with different values <fossy>but its a pretty simple package <fossy>gforce_d11977: i did extract the vmlinux from your very useful chroot mode and then try to kexec it on anther system ***mephista is now known as spicy_icecream
<stikonas>fossy: oh you now downloading directly into tmp? <stikonas>if some upstream mirror is gone, we might not have any copy of tarballs <stikonas>maybe it's better to download into .gitignored files in sysa/*/src? <stikonas>bauen1: which musl version were you using? <bauen1>stikonas: my myunix fork is based of v1.2.1 <bauen1>so of commit 73cc775bee53300c7cf759f37580220b18ac13d3 <stikonas>although, I think that commit is too new for mes libc <stikonas>I think we can build up to something in 2019 <stikonas>pder: by the way, coreutils cut is also a bit broken, some memory allocation problems <siraben>"How does Clang 2.7 hold up in 2021? (gist.github.com)" <bauen1>isn't that not actually too bad ? <bauen1>you (ideally) only compile once and then run the resulting object a lot more often <xentrac>bauen1: the situation is dramatically worse than Proebsting had said, with respect to C compilers at least <stikonas>well, you can't expect exponential increase for that long... <pder>stikonas: I looked at cut and its a strange bug. cut seems to work fine with reading from files, but when reading from stdin is when you get the memory exhausted error <pder>in lib/getstr.c on line 54, there is a check for !lineptr || !n || !stream. But if stream is stdin which is 0, that function will always return an error <pder>Not sure how that code ever would normally work <fossy>I think source not existing is a seperate problem <fossy>we should address that in a separate script or smth <fossy>or maybe a completely separate project <fossy>stikonas: try 1.1.x series, it is very more simple iirc <stikonas>by the way, I briefly tried to check tcc -ar issue... <stikonas>probably somewhere lower in the stack there is a 1024 byte buffer <stikonas>there are quite a few places hardcoding 1024 byte buffers <fossy>I think you could be right...n <fossy>tcc probably has some kind of max length constant for argv <stikonas>but in any case I think we have to go for musl... <stikonas>basically everything else I tried needs more libs <stikonas>fossy: so the first error that I get when building musl now is "./arch/i386/syscall_arch.h:40: error: incorrect prefix" <stikonas>(ignoring those static errors that are either patchable or newer tcc works on them) <stikonas>that disappears with -DSYSCALL_NO_TLS but I'm not sure if we are allowed to use it... <fossy>the question is if that macro is correct. <stikonas>but somehow it's not triggered on two earlier macros <stikonas>and if I comment it out, then following macros again all trigger it <stikonas>and I configure musl with CC=tcc AR="tcc -ar" RANLIB=true ./configure --host=i386 --disable-shared <fossy>stikonas: is SYSCALL_INSNS defined <stikonas>fossy: well, it's either one or the other <stikonas>normally it would be #define SYSCALL_INSNS "call *%gs:16" <stikonas>it does compile with #define SYSCALL_INSNS "int $128" <stikonas>but I guess it would crash later if we use int instruction <stikonas>so tcc prints incorrect prefix in i386-asm.c if (pop->type != OP_SEG || seg_prefix) <stikonas>I guess seg_prefix is %gs in this case so 0x65 <stikonas>so seg_prefix on its own triggers that condition <stikonas>and OP_SEG is I guess 1 << 8 so not equal to pop->typo <stikonas>early 1.1.x version don't work, due to other errors, but 1.1.20 might work <stikonas>ok, now I got src/fcntl/fcntl.c:12: warning: implicit declaration of function '__builtin_va_start' <stikonas>fossy: now I get src/fenv/i386/fenv.s:20: error: unknown opcode 'stmxcsr' <stikonas>(and I also don't know) need to go read docs... <bauen1>stikonas: there's a few others, try running make with `--keep-going` to find most of the issues <bauen1>might be few enough to hand assemble it <stikonas>and one more that I think I knew how to fix <stikonas>that had jecxz 1f which I replaced with cmp %ecx, 0 and je 1f <stikonas>bauen1: fossy, so I think only those two issues, stmxcsr in fenv.s and jecxz in signal/i386/sigsetjmp.s which I think I replaced (but would be good if somebody knowing more assembly confirm that my fix is valid) <bauen1>stikonas: did you hand-assemble them or did you replace them with equivilent instruction sequences ? <stikonas>oh, I tried replacing with equivalent instruction sequence <stikonas>but I only did one for now ( and it needs reviewing) <stikonas>can I have 0 as cmp operand or does it have to be register? <stikonas>all of this if floating point code, so hopefully not too critical <stikonas>argh, now I got the same error I was getting with earlier musl: src/internal/i386/syscall.s:27: error: bad expression syntax [[] <stikonas>I deleted those offending fenv.s lines for now <stikonas>hmm, after I removed those lines, I get the same crash that I had when I initially compiled with -DSYSCALL_NO_TLS... <stikonas>so maybe that was fine and the problem is elsewhere... <bauen1>stikonas: a_crash is a musl helper that gets called (in code) when something is wrong, so it should be easy to find where <stikonas>hmm /* Failure to initialize thread pointer is always fatal. */ if (__init_tp(__copy_tls(mem)) < 0) <stikonas>oh, actually, that fix helped, it just crashes later <stikonas>still quite a bit of work to automate musl... <stikonas>fossy: should we keep musl binaries in the same prefix /after?