IRC channel logs

2023-05-23.log

back to list of logs

<stikonas>janneke: sigh, so far fairly negative progress today...
<stikonas>after some rebasing I can't even get riscv64 version of mes-m2 to work (it runs and exits with 0 status without doing much...)
<stikonas>ok, found one issue, slightly better now but there is probably another
<stikonas>janneke: anyway, for now I've replaced those ld !-0x10 with ld !-16...
<stikonas>but somehow mes-m2 enters interactive mode after running script
<stikonas> https://paste.debian.net/1280913/
<stikonas>janneke: and also note that I've completely unified stage0-posix-riscv64 and mes defines
<stikonas>but that means that you need the very latest M2-Planet
<stikonas>(from the last git commit)
<stikonas>hmm, probably something still broken with exit call...
<stikonas>oh, syscall number was incorrect...
<stikonas>ok, I've pushed updated version
<stikonas>so mes-m2 should be functional now...
<theruran>is amd64 on stage0-posix finished? I am running Release_1.5.0 and it is stuck on:
<theruran>+> ./AMD64/artifact/cc_amd64 ./AMD64/artifact/M2-0.c ./AMD64/artifact/M2-0.M1
<theruran>on my other machine which is musl-based, it actually completes but gives me mismatching hashes for several binaries
<stikonas>theruran: it is finished
<stikonas>and none of the musl stuff should matter
<stikonas>none of it is used
<stikonas>theruran: maybe submodules are out of date?
<stikonas>theruran: and in general I suggest running the latest git
<stikonas>still it's a bit strange that it's stuck...
<theruran>lemme try master HEAD again. yeah, i made sure to update the submodules
<theruran>and do a ./cleanup.sh
<theruran>iunno. now it's stuck at +> ./AMD64/artifact/M0 ./AMD64/cc_amd64.M1 ./AMD64/artifact/cc_amd64.hex2
<oriansj>theruran: well that step is known to be slow (as it is only reading 1 byte per syscall)
<theruran>OK it has moved on to +> ./AMD64/artifact/cc_amd64 ./AMD64/artifact/M2-0.c ./AMD64/artifact/M2-0.M1
<janneke>stikonas[m]: so, some good progress after all, nice
<stikonas[m]>janneke: well, at least I should have umblocked mes-m2 build...
<stikonas[m]>Though for mescc devel, running x86 version is faster
<stikonas[m]>Anyway, scaffold-global array crashes for me...
<oriansj>theruran: honestly with just a handful of extra functions all of those early programs could be made much faster. But I traded speed for simplicity as auditing another hundred bytes of hex0 is just no fun.
<stikonas[m]>Well, hex2 is written in hex1, so it's a bit better but still...
<gforce_de1977>@oriansj - trading speed for simplicity is very wise here
<stikonas[m]>Still it's strange that it takes a long time. On my laptop native (non qemu'd) stage0-posix takes a minute or two, and early stages are just seconds...
<theruran>it's still moving along, at least. but I swear last time it was stuck overnight
<stikonas[m]>theruran: maybe check what takes so long?
<stikonas[m]>Is it really I/O?
<stikonas[m]>`strace -T` might be useful
<theruran>stikonas[m]: looks like it is write()'ing 1 byte at a time
<stikonas[m]>theruran: yes, that's true
<stikonas[m]>That's the optimisation oriansj talked about
<theruran>it was much faster on my Void musl machine. I may have some kernel settings enabled here, in addition to disk encryption and hardened toolchain that may slow it down?
<stikonas[m]>There is no buffering until much later... (M2libc)
<stikonas[m]>I have disk encryption too
<stikonas[m]>Hmm
<stikonas[m]>You can try running it in /dev/shm
<stikonas[m]>(Or any other tmpfs)
<janneke>so, on a completetly (?) unrelated note...
<janneke> https://todon.nl/@janneke/110419350822212613
<stikonas>what is rumpdisk?
<janneke>rumpdisk is a server for the hurd, based on the netbsd rumpkernel
<janneke>it brings modern disk support to the hurd
<janneke> https://archive.fosdem.org/2022/schedule/event/dzammit/
<muurkha>"The figurative sense of "small remnant, tail-end of anything" derives from the notion of "tail" and is recorded from 1640s in reference to the English Rump Parliament (December 1648-April 1653), so called from sitting after the expulsion of the majority of members of the Long Parliament in Pride's Purge. As an adjective from c. 1600."
<muurkha>thus we have rump sessions at conferences and rump kernels, I suppose?