IRC channel logs

<gnu_srs2>Hi, which program/script detects if filesystem partitions are corrupt?

<ahenv>gnu_srs2: may be, "compgen -c" in bash can list all available commands

<gnu_srs2>with a working bootlogd i would have known. Unfortunately it does not work on Hurd :(

<Pellescours>fsck?

<solid_black>signal handling is working!!

<biblio>solid_black: signal handling for aarch64-gnu ?

<azert>solid_black: yay!

<azert>What’s missing now?

<solid_black_>biblio: yes :)

<solid_black>azert: next up: posting the glibc and Hurd patchsets

<solid_black>gnumach, I'm not sure

<solid_black>I can post it as an RFC

<azert>Great news!

<azert>Im sure you also fixed some bugs

<solid_black>the main still-missing thing is being more serious about hardware in gnumach

<solid_black>we should at least get device_read() / device_write() hooked up to UART

<solid_black>and add support for more models of interrupt controllers and UARTs

<solid_black>if you're interested in working on this, please do!

<azert>That would be great. I don’t think you can support the whole ecosystem by yourself. If you have something minimal but working it will be very useful.

<azert>The way I could see myself working on this is to install it on a dev board and filling in the missing bits to make its uart working

<solid_black>oh, real hardware is going to be even more fun

<solid_black>for now I'm running this in qemu-system-aarch64 on a x86_64 host

<biblio>solid_black: glad to hear. :)

<solid_black>which, AIUI, means that I don't get any of the weak memory ordering effects

<solid_black>Mach is going to need some upgrades to start using atomics properly

<azert>We will never know until we try!

<solid_black>yeah

<solid_black>do you want to try running aarch64 gnumach in qemu?

<solid_black>I could try to guide you through setting it up, if you want to

<azert>I can try but I need docs

<azert>Please do

<solid_black>le docs, c'est moi :)

<solid_black>(les docs?)

<solid_black>ok, so you need to start by building a cross-toolchain

<azert>les

<solid_black>pick a prefix dir (in my case, PREFIX=~/dev/crosshurd-aarch64), mkdir $PREFIX/{src,include,aarch64-gnu}, ln -s ../include $PREFIX/aarch64-gnu/sys-include, ln -s ../lib $PREFIX/aarch64-gnu/lib

<solid_black>then unpack (git clone) fresh binutils into $PREFIX/src/binutils, and do mkdir build && cd build && ../configure --target=aarch64-gnu --prefix=$PREFIX --with-lib-path=$PREFIX/lib && make && make install

<solid_black>(does that make sense?)

<azert>Yes

<azert>Absolutely

<solid_black>so, uh, tell me when you're done with that, and I'll tell you for to do next

<solid_black>s/for/what/

<azert>I’ll get back to you

<gnu_srs2>(09:50:22) gnu_srs2: Hi, which program/script detects if filesystem partitions are corrupt?

<gnu_srs2>(11:36:49) gnu_srs2: with a working bootlogd i would have known. Unfortunately it does not work on Hurd :(

<gnu_srs2>boot sequence: gnumach->grub->/etc/hurd/runsystem.sysv:fsysopts / --update --readonly;exec ${init} ${single} -a; then what??

<solid_black>gnu_srs2: then it's just whatever ${init} is; sysv init on Debian GNU/Hurd

<gnu_srs2>{init}=/sbin/init

<gnu_srs2>from sysvinit-core

<gnu_srs2>Where does the partition checks come into play?

<azert>solid_black: done that, it worked

<solid_black>cool

<solid_black>add $PREFIX/bin to path, and check that e.g. aarch64-gnu-nm --version works

<azert>Yes, it says 2.24.50.20240320

<azert>GNU spartan assembler is installef

<solid_black>2.24, not 2.42?

<solid_black>next up: unpack or clone GCC under $PREFIX/src/gcc, and apply these 3 patches adding aarch64-gnu support: https://lists.gnu.org/archive/html/bug-hurd/2024-01/msg00002.html

<azert>Ok..

<solid_black>then configure/make incantation is: ../configure --prefix=$PREFIX --target=aarch64-gnu --with-lib-path=$PREFIX/lib --disable-multilib --enable-languages=c && make all-gcc && make install-gcc

<azert>The patches don’t apply, can you send them using a paste site?

<solid_black>let me try

<azert>Im afraid copying the web page corrupt them

<solid_black>here you go https://paste.gg/p/anonymous/6377b0d5181b4f0e85ca19c377308e25

<solid_black>you should be able to fetch them using the "raw" links without copyin text from the browser

<solid_black>so, did it work?

<azert>The third patch doesn’t apply on gut anymore but I fixed it

<azert>On git, they changed the Linux trampoline

<azert>Hope the new one works too

<solid_black>ok, thanks, I'll rebase it on my end too then, and re-send instead of just pinging them

<azert>gcc is installed on my end

<solid_black>you mean you built and installed aarch64-gnu-gcc?

<azert>Yes

<solid_black>cool

<solid_black>next up, Mach headers!

<solid_black>cd $PREFIX/src && git clone git://git.savannah.gnu.org/hurd/gnumach.git && cd gnumach && git remote add bugaevc https://github.com/bugaevc/gnumach.git && git fetch bugaevc && git switch -c wip-aarch64 bugaevc/wip-aarch64

<solid_black>autoreconf -i && mkdir build && cd build && CC=gcc ../configure --prefix=$PREFIX --host=aarch64-gnu && make install-data

<solid_black>note the CC=gcc to tell it to not use aarch64-gnu-gcc ust yet

<azert>solid_black: it worked

<solid_black>yay, so you should have various headers now, in particular something about aarch64_thread_state in $PREFIX/include/mach/aarch64/thread_status.h, right?

<ahenv>I don't get (understand) this: <azert> "You can perhaps start by generating an embedding"

<azert>Yes I do

<solid_black>next step is building MIG

<solid_black>cd $PREFIX/src && git clone git://git.savannah.gnu.org/hurd/mig.git && cd mig && autoreconf -i && mkdir build && cd build && ../configure --target=aarch64-gnu --prefix=$PREFIX && make && make install

<solid_black>(no patches needed, it just works)

<azert>Should I add $PREFIX/bin to my $PATH?

<solid_black>yes

<solid_black>well actually I guess this is somewhat wrong, because this puts libraries/binaries for the target system with the libraries/binaries of the cross toolchain

<solid_black>haven't caused me any issues so far though

<solid_black>but you could have separate bin/ and cross-bin/ and so on

<azert>Worked for me

<solid_black>so did mig build?

<azert>Yes

<solid_black>cool, so now you can go back to Mach and actually build it

<solid_black>rm -r build && mkdir build && cd build && ../configure --prefix=$PREFIX --host=aarch64-gnu && make

<solid_black>after that you should have build/gnumach and build/gnumach.elf

<azert>I get an error

<azert>struct per_cpu had no curr_ip’

<azert>curr_ipl

<solid_black>indeed, I removed curr_ipl ust yesterday

<solid_black>which file is the error in?

<solid_black>oh it is aarch64asm

<solid_black>must be that

<azert>Yes

<solid_black>there is some issue with the buildsystem, it doesn't see what that file depends on, and doesn't rebuild it when things change

<azert>How do you rebuild it?

<solid_black>no, I mean that's why I haven't seen the error

<solid_black>let me push the fix

<solid_black>pushed

<azert>It cannot find libgcc

<azert>How do I export it’s path?

<solid_black>huh, so it does need libgcc, fun

<solid_black>ok, I hoped we could skip that step

<solid_black>no, you don't have libgcc because we haven't built it

<solid_black>let's do that now then

<solid_black>uhh, but you're going to need my glibc patches, and I haven't pushed those

<solid_black>let me set up a github repo I guess

<solid_black> https://github.com/bugaevc/glibc.git, aarch64-gnu branch, consider using --depth when cloning

<solid_black>azert: ping

<azert>solid_black: I’m tracking your branch

<solid_black>ok

<solid_black>you actually need to install hurd headers first, so I set up a repo for that too

<solid_black>github.com/bugaevc/hurd.git, aarch64 branch

<azert>Tracking that too

<solid_black>autoreconf -i && mkdir build && cd build && CC=gcc ../configure --host=aarch64-gnu --without-parted --without-libcrypt --without-libbz2 --without-libz --without-rump && make no_deps=t prefix=$PREFIX install-headers

<solid_black>that's in hurd/

<azert>Done

<solid_black>now, glibc headers

<solid_black>mkdir build && cd build && ../configure --host=aarch64-gnu --prefix= && make install-headers DESTDIR=$PREFIX

<solid_black>that's not a typo, --prefix= (empty string) in configure line

<azert>Worked

<solid_black>cool, now you should be able to build libgcc

<solid_black>or no, wait, one more thing

<solid_black>touch $PREFIX/include/gnu/stubs.h $PREFIX/lib/libc.so && make csu/subdir_lib && install csu/crt1.o csu/crti.o csu/crtn.o $PREFIX/lib

<solid_black>I don't know what that does or why that is required, don't ask

<solid_black>after that, go back to gcc/build and make configure-target-libgcc && make all-target-libgcc && make install-target-libgcc

<solid_black>after that, go back to gnumach, and hopefully it should link

<azert>file gnumach: Linux kernel arm64

<azert>:)

<solid_black>yay!

<solid_black>see aarch64/BOOTING

<solid_black>you might want to build mach's self-tests to get some simple userland executables

<solid_black>there's probably some proper way to do it (Luca would know), but I've been just doing make tests/module-{hello,gsync,mach_host,machmsg,mach_port,syscalls,task,threads,vm,thread-state}

<solid_black>you might need to run it twice if it doesn't succeed the first time

<solid_black>after that, for test in gsync hello mach_host machmsg mach_port syscalls task threads vm; do qemu-system-aarch64 -m 1G -machine virt -cpu max -kernel build/gnumach -nographic -append "foo=bar" -device guest-loader,kernel=build/tests/module-$test,bootargs="module-$test "'${host-port} ${device-port} $(task-create) $(task-resume)',addr=0x4000; done is a command that runs all those test one by one

<solid_black>actually not all of them, missing thread-state

<azert>How do I know if they are working?

<azert>I run your command and it seems stuck in qemu

<solid_black>if they print "gnumach-test-success-and-reboot: test module-something exit code 0", it worked

<solid_black>hm, so does it print anything at all?

<azert>How long should it take?

<azert>Yes it doesn’t print anythibg

<solid_black>test-threads sleeps for a few seconds, the others should be instant

<solid_black>hmm

<solid_black>lets try to debug it I guess

<solid_black>or, I wonder, could this be dependent on qemu version? I have 8.1.3

<solid_black>could it be that they've changed something about the "virt" machine that I've hardcoded

<azert>8.2.1 over here

<azert>Debian sid

<solid_black>do you know how to use qemu's gdbstub? i.e. -s and target remote

<azert>No

<solid_black>ok, I'll walk you through i

<solid_black>it

<solid_black>run qemu-system-aarch64 -m 1G -machine virt -cpu max -kernel gnumach -nographic -append "foo=bar" -device guest-loader,kernel=tests/module-$test,bootargs="module-$test "'${host-port} ${device-port} $(task-create) $(task-resume)',addr=0x4000 -s -S, it should output nothing and hang

<solid_black>in another terminal (tab), run gdb, enter "tar ext :1234", then "p $pc", what does that print?

<solid_black>err, I meant to replace $test with hello

<solid_black>qemu-system-aarch64 -m 1G -machine virt -cpu max -kernel gnumach -nographic -append "foo=bar" -device guest-loader,kernel=tests/module-hello,bootargs="module-hello "'${host-port} ${device-port} $(task-create) $(task-resume)',addr=0x4000

<solid_black>-s -S

<azert>Pc is in 0x40000000

<solid_black>right, mine starts there as well

<solid_black>now in gdb, enter "si" 6 times, $pc should jump to 0x0000000040200000 or so

<azert>Yrp

<azert>Yep

<solid_black>now do symbol-file gnumach.elf -o $pc

<solid_black>and confirm

<solid_black>and you should discover that you're at the very first byte of gnumach

<solid_black>do you know how to use gdb in general?

<azert>Yrs

<azert>We are in _text_start