IRC channel logs
2024-06-13.log
back to list of logs
<oriansj>aggi: thank you for a greater understanding of the tccboot situation. <oriansj>cosinusoidally: yeah depending upon that behavior probably wasn't wise to begin with. <matrix_bridge><cosinusoidally> Though Linux doesn't use semver so I'm not sure how early of a 2.6 kernel it works on <matrix_bridge><Andrius Štikonas> cosinusoidally: well, you can try to fix that <matrix_bridge><Andrius Štikonas> we have a few versions that don't depend on that behaviour <matrix_bridge><Andrius Štikonas> I don't remember for sure but stage0-riscv64 might be better behaving too <matrix_bridge><cosinusoidally> I might give that a go some point. Is there an easy way of generating hex2_x86.hex1 from hex2_x86.M1 ? <oriansj>cosinusoidally: unfortunately not as they were hand written. But the fix is just replacing 3-4 hex chars in the elf-header <pabs3>from #debian-ports <hephaistor> huh, apparently, gccrs now needs cargo to bootstrap, hahahaha… there goes another way to bootstrap stuff <oriansj>well that fits. GCC's C compiler needs a C++ compiler and GCC's Ada compiler requires an Ada Compiler <oriansj>Good thing we already have a bootstrap path for Rust and Cargo <lanodan>Hopefully mrustc directly to gccrs still works, compiling something like ~20 versions of rustc isn't fun, specially as LLVM is involved <matrix_bridge><Andrius Štikonas> yeah, I was a bit sceptical before about gccrs, I never saw any attempt to bootstrap cargo there unlike mrustc's minicargo. So I guess now it is official <matrix_bridge><cosinusoidally> oriansj: ah thanks I didn't think of just bumping ph_memsz in hex2_x86.hex1 . I set it to FF FF 00 00 (but probably could have just been 4KB) and that seemed to fix it on a 2.4 kernel. Unfortunately kaem-minimal.hex0 also seems to be broken, though I might be on an older version. I was able to temp hack around that by using sh. <oriansj>cosinusoidally: what sort of broken behavior do you see? <oriansj>segfaults or hangs or something else? <matrix_bridge><cosinusoidally> segfault, but I haven't dug into it that much <matrix_bridge><cosinusoidally> oriansj: turned out to be some issue with either sed or xxd on Slackware 8.1. I was generating the seeds with "sed 's/[;#].*$//g' x86/kaem-minimal.hex0 | xxd -r -p > x86/artifact/kaem-optional-seed" but the output file was about 12 bytes shorter than it should have been. A kaem-optional-seed generated by my Ubuntu 22.04 host did work when transferred to the slackware vm <oriansj>what the 12 byte difference is would certainly be interesting to see and to figure out the why. <oriansj>perhaps the sed is producing different inputs or xxd is behaving differently (either would certainly be quite unexpected) <matrix_bridge><cosinusoidally> Looks like there is some character in kaem-minimal.hex0 that this 22 year old version of xxd doesn't like. From the manpage "xxd -r never generates parse errors. Garbage is silently skipped." <matrix_bridge><cosinusoidally> I deleted some comments/whitespace and xxd was then able to parse <stikonas>any reason why you didn't use bootstrap seeds repo? <matrix_bridge><cosinusoidally> I was actually trying to run my tcc_bootstrap_alt and I do not rely on the bootstrap seeds repo. <matrix_bridge><cosinusoidally> even when I run stage0-posix-x86 I tend to generate the seeds myself rather than depend on the binary bootstrap seeds <oriansj>cosinusoidally: now that is interesting because sed should have removed all of the comments prior to xxd running <oriansj>and the only characters that xxd should be seeing are A-F, 0-9, ' ', '\n' and '\t' <stikonas>well, binaries of sed and xxd are far far larger than hex0 <stikonas>even the hexeditor is far larger if you type if yourself <oriansj>and we do have hex0.c which you can build which is quite small as well