<stikonas>older defines are only used in earlier development prototypes (hex0 to M0) <stikonas>and given that cc_amd64 is vastly bigger, switching the rest to new defines shouldn't be hard <stikonas>anyway, that's early stage0-posix stuff without M2libc <stikonas>yes, rbp offsets rather than rsp offset work much better for asm functions in UEFI <stikonas>one reason is that we need to do some stack pushes in UEFI calling convention, which messes rsp offsets up but does not affect rbp offsets <stikonas>and secondly, rbp offets go from first argument to last, so maybe tiny bit more readable than reverse order... ***ChanServ sets mode: +o janneke
<USA-RedDragon>Hello! I recently made an issue in the fosslinux/live-bootstrap repo expressing interest in working on AArch64 support. My usecase is that I'm unenthused by the state of bootstrapping toolchains (and to a larger extent a Linux distribution) and would like to apply this towards a personal Raspberry Pi CM4 project. Bootstrapping remains difficult, so I would like to put effort in where it can matter (i.e. extending this <USA-RedDragon>project if possible) rather than waste the effort on yet another fragile or self-dependent bootstrap. <USA-RedDragon>I've gotten to the point of mescc-tools-extra getting compiled, but I fail with `cp` throwing a SIGSEGV trying to copy $arch/bin/blood-elf to /usr/bin. It seems to be during the fputc/fgetc while loop of copy_file <USA-RedDragon>If I knew how to hook into this process with gdb or the likes, it'd be a lot simpler than my awful `fputs` to stdout debugging <stikonas[m]>USA-RedDragon: throw in some bad command before cp and then run cp manually with gdb <fossy>USA-RedDragon: hey! you can run the bootstrap with ./rootfs.py -cp (chroot mode, preserve the chroot after exit). once something goes wrong, you can peruse the binaries (inc w gdb) to your will. <fossy>i assume you have ensured that cp works with gcc? you can compile mescc-tools-extra from outside live-bootstrap. (i *highly* doubt that it wouldn't, but good to check anyways) <fossy>when debugging live-bootstrap it's usually best in the early stages to do the majority of debugging on the broken binaries from outside the live-bootstrap environment <USA-RedDragon>Thanks for the help, y'all. I'm switching over to my RPI to use chroot. For some reason binfmt isn't playing nicely with chroot on my main host, and I think even the RPI's bare metal should be faster than qemu was. <stikonas[m]>USA-RedDragon: probably misconfigured binfmt... It works for me for all arches that stage0-posix supports <stikonas[m]>On qemu stage0-posix takes about 2 min for me, but native build on rockpro64 is much faster, maybe 20s <stikonas[m]>And live-bootsrap will need some changes go support multi arch <stikonas[m]>So that at least ARCH variable is exposed and you can run conditional code <USA-RedDragon>Update: cp doesn't work, catm does. Gonna dig into it with GDB tomorrow <stikonas[m]>That is strange, they both should be using fgetc to read and fputc to write <stikonas[m]>Also as fossy, said worth trying to check GCC/glibc compiled cp from mescc-tools-extra <stikonas[m]>If you can reproduce crash there, then it might be easier to debug in gdb <USA-RedDragon>AArch64 `cp` issue update: It's the chroot environment that's causing the failure. The destination directory (`/usr/bin`) isn't being created by `mkdir`. I have a suspicion that this `mkdir` might be hitting the no-op `sys/stat.h` `mkdir` function, as there is no error logged by the return code <USA-RedDragon>Hrm so running that mkdir outside of the chroot can't make directories either. It errors if I try to `mkdir DIRNAME` with 'Could not create directory', but with `-p` no directory is created, but the error is swallowed <USA-RedDragon>`-p` swallowing the error/exit code is a logic issue in the `mkdir` impl. Not the root cause of the failure though <stikonas>USA-RedDragon: possibly syscall not implemented <stikonas>I think stage0-posix-aarch64 builds mkdir but does not use it <stikonas>USA-RedDragon: hmm, though it seems to have code for it <stikonas>and aarch64 uses not those older style DEFINES, might be a bit unfamiliar to those who used GAS syntax... <stikonas>and then we'll have probably the first ever self-hosting compiler running on UEFI ***pgreco_ is now known as pgreco
<USA-RedDragon>I'm thinking the syscall number is wrong. Was getting set as dec 1030, whereas dec 34 is appropriate for arm64. <stikonas>USA-RedDragon: 34 is mkdir_at for aarch64 <stikonas>especially given that SET_X0_TO_FCNTL_H_AT_FDCWD <stikonas>yes, mkdir itself is not available on arm64... <stikonas>USA-RedDragon: indeed, I've just check with strace, I get the following <stikonas>syscall_0x406(0xffffffffffffff9c, 0x7ffe0d1ff2, 0x1ed, 0, 0, 0) = -1 ENOSYS <stikonas>USA-RedDragon: could you fix this and make a PR? <USA-RedDragon>I can do that. I have a question about what's going on before the syscall. It seems to be taking parameters and putting them in the right registers, but it keeps bringing them to X0, then to the destination register. Is there some calling convention I'm missing here? This is the original asm <https://gist.github.com/USA-RedDragon/09e9b2a6cd5ae06a0aee813ec85b136a>, and this is what I'm using to sanity check, which does work, <stikonas[m]>I'm not too familiar with aarch64 but part of it might be just an attempt to use fewer different instructions <stikonas[m]>But in general M2-Planet puts function arguments onto stack <stikonas[m]>Then you can access those function arguments relative to either base or stack register <stikonas[m]>If you look at my PR above, I'm also adding those C wrappers around asm (but for amd64)