IRC channel logs
2023-12-09.log
back to list of logs
<mihi>(the coincidence being me running into that exact same issue this week) <stikonas>but at least linux kernel does not crash if you do syscall with non-aligned stack <mihi>I guess kernel does not have that much use for XMM vector maths (which require 16-bit aligned addresses) <mihi>in higher code (M2libc) you can probably dynamically fix alignment, and make sure the last value you push is the original stack pointer so you can go back on return. <stikonas>yeah, we'll have to somehow dynamically fix allignment <stikonas>not sure if that will need changes to M2-Planet <stikonas>since I can only reproduce it on real HW... <oriansj>well the easiest way in M2-Planet is add some logic to function calls to add some push nulls befor pushing actual values <stikonas>well, we either need to add push 0 or nothing <stikonas>you need to keep track of stack pointer... <stikonas>(also call instructions move it by 8 as well...) <stikonas>anyway, I think that was the issue for stage0-uefi not working on my machine <stikonas>with a few pushes and pops I've now got it to output first byte... <stikonas>anyway, need to do it in a bit more systematic way... <stikonas>oriansj: I think this should also work in M2libc... <stikonas>perhaps no changes are needed in M2-Planet then <oriansj>well M2-Planet does know the exact number of arguments it needs to push onto the stack for every function call but if that stack behavior only matters for UEFI calls; then yeah we could do it easier in M2libc <stikonas>well, but compiler might not know whether stack is currently 16-byte aligned <stikonas>e.g. it might be recursion and function can have different depths <stikonas>before each UEFI call we need to place and rsp, -16 <stikonas>(depending on whether we have even or odd number of stack pushes between "and rsp, -16" and call <npcomp>Is there a preferred minimal VM image that is used to execute the bootstrap seeds? <oriansj>npcomp: nope, it is very much bootstrap as you like. <npcomp>Ok, so oriansj , I executed the bootstrap seed and ended up with my binaries, I suppose my goal is to end up with a bootable guix image? Is fosslinux/live-bootstrap the intervening step I need? <matrix_bridge><Andrius Štikonas> npcomp: live-bootstrap should give you a good headstart <matrix_bridge><Andrius Štikonas> But after it you'll have to bootstrap guix manually <matrix_bridge><Andrius Štikonas> (Though you'll already have GCC/Guile and other stuff) <stikonas>ok, I think I fixed hex0.S in stage0-uefi... <stikonas>well, my implementation of UEFI only needs rbp restored, but probably safer to save/restore all non-volatile registers as the spec requires <stikonas>hmm, that's extra 57 byte increase from 832 to 889 for hex0.efi <stikonas>but oh well, we must be spec compatible for it to work anyway <matrix_bridge><cosinusoidally> It can't yet mark itself as executable so you need a chmod +x ../artifacts/tcc_27_boot_static.exe . It can rebuild itself (see run_27_static.sh). <matrix_bridge><cosinusoidally> fragile to the extent that I tried moving around some lines in my libc_static.c to make it less messy, but then it broke and I had to revert it. <stikonas>oriansj: what's the correct way of dealing with A displacement of 38242 does not fit in 2 bytes <stikonas>I've now got this complaint in M1 when it saw immediate @0x9562 <stikonas>I guess this is one of the new range checks... <stikonas>hmm, this probably breaks all later UEFI apps... <stikonas>(though is not an immediate blocker for me) <stikonas>but once I reach fixing cc_amd64.efi it will be... <oriansj>stikonas: use a 4byte or 8byte pointer <stikonas>hmm, so I should merge those 2 contants into one? <stikonas>oriansj: by the way, I've now fixed hex0 for UEFI, we'll have to update bootstrap seed <stikonas>oriansj: yeah, it's just a struct with data <oriansj>just like % is signed 32bit and & is unsigned 32bit <stikonas>I forgot that we have more of those labels <oriansj>only ! is used for both because # was already assigned for comments <oriansj>and I was doing a shift by 2 on the keyboard pattern <stikonas>anyway, I fixed it for hex0.M1. Other files will need fixing too but I'll just do it at the same time as I fix stack alignment and saving non-volatile registers <stikonas>oriansj: so I think we can do all alighnment in M2libc later using the same technique... <stikonas>basically push rsp; push [rsp]; and rsp, -16; {possibly another push} ... call; mov rsp, [rsp+XX] <stikonas>and will align stack to 16 bytes and then last mov will restore stack pointer from one of the first 2 pushes (depending on whether and rsp, -16 moved rsp or not) <oriansj>or skip the pushes entirely; make a stack frame using add rsp, $framesize and remove the stack frame using sub rsp $framesize <oriansj>wasteful and inefficient but ensures the stack frame is always aligned. <oriansj>sometimes I wonder if the poorly written bios are the side effect of bad programmers or an intensional design to make it trivial to write a replacement because it is so buggy <stikonas>oriansj: well, in this particular case it's actually foss edk2 version... <oriansj>foss software doesn't ensure well made software by people who know what they are doing, just that others can build upon that work <oriansj>and that is ok. Smart capable people are rare and take a great deal of community effort to develop <stikonas>yeah, though I wonder how much is edk2 developed by community people... <stikonas>it might be mostly corporation driven... <oriansj>have you ever seen the talk open source success? <stikonas>hmm, while working on kaem, I think I should be able to make some optizations to hex0 alignment and get a few bytes back... <stikonas>the not nice thing is that I might need to reencode hex0 code... <stikonas>but usually those very minor tweaks are not too bad <oriansj>well hex0 is the worst bootstrapping language <oriansj>but it works in the make art one grain of sand at a time sort of thinng <stikonas>and hex0 for amd64 is still much easier to edit than riscv64... <stikonas>you could easily write M0 defines there by just looking at a few pages of riscv specs <oriansj>yeah, risc-v might be very efficient of a hardware design but its low level layout leaves much to be desired. <oriansj>and in retrospect x86 should have been done in octal then it would have had beautiful M0 defines <oriansj>and thanks to muurkha we know the octal hex0 would be much smaller <stikonas>hmm, I think I can save 3 bytes so instead of increase of 57, it would be 54 <oriansj>just need to add some logic for line comments and it'll be a significant size reduction for x86's bootstrap starting binary. <oriansj>then x86's bootstrap path could be octal0, octal1, octal2, M0, cc_x86 and the result would be a good bit cleaner. <stikonas>well, in principle just one set of comments would be sufficient... <stikonas>you could always distinguish them by doing something like 6A 01 ; push !1 ;; push to stack <oriansj>true for the initial seed, one doesn't need to support all of the extra features or sanity checking <stikonas>oriansj: you can slash some bytes with pushes instead of assinments <stikonas>mov esi, -4 is longer than push !-4; pop esi <oriansj>well I finally found a usecase for usleep in M2libc <oriansj>using a C program buildable by M2-Planet <oriansj>certainly would be more entertaining way to pass the time while the bootstrap progresses on fiwix than donut.c (which M2-Planet can also build) <muurkha>I had explained the algorithm to a friend of mine and shown him the code, but he couldn't understand what I was talking about <muurkha>so I figured the visualization would help <oriansj>sometimes it does, but depends upon the person. <oriansj>and the people who don't care to learn, tend to be quite impossible to explain the why and how to. <muurkha>you could maybe make donut.c interactive in some way. have you seen the recent stuff about "Gaussian splatting"? <oriansj>well then I would also have to add mouse support or something <muurkha>is this a deobfuscated version of donut.c? <oriansj>and changes to make it buildable via M2-Planet <muurkha>mice can be nice for navigating 3-D worlds and building models