IRC channel logs

<stikonas>fossy: so on my laptop I'm seeing that not rebuilding mes is faster

<stikonas>there is some variation, but perhaps we spend ~3 minutes rebuilding mes but lose ~2 minutes because mes-m2 is slower

<stikonas> https://github.com/fosslinux/live-bootstrap/pull/515

<oriansj>hmmm, I might be able to make M1 for knight more standard, without breaking legacy M0 code.

<oriansj>ok fixes to M1 are up

<oriansj>and I should have M0 in knight's bootstrap tree fixed next week;

<oriansj>although i might switch PowerPC to word instead of byte first

<stikonas>oriansj: for M2-Planet?

<stikonas>and mescc-tools?

<stikonas>I don't think we have stage0-powerpc

<oriansj>we just have some basic support for powerpc in mescc-tools

<stikonas>oh indeed

<stikonas>M2-Planet doesn't have any

<oriansj>that is because the byte form for powerpc is really ugly and I refused to do all that work until it is much cleaner.

<oriansj>but it's assembly will be much easier than risc-v because it is much richer

<stikonas>well, in risc-v the main problem was early hex programs...

<stikonas>encoding all those shifted bits is hard, at least if you do it by hand

<oriansj>after that it'll be IBM S/390, SPARC and Alpha

<stikonas>do we need word-form for aarch64?

<stikonas>I think aarch64 is also fixed size

<oriansj>well word form would make aarch64 much cleaner

<oriansj>but it also would require a bunch of rework

<stikonas>yeah...

<stikonas>and we don't have many volunteers

<oriansj>so, yes it would be nice but also be a major project for anyone who wanted to do it

<oriansj>I may go back and redo it in a couple year after I finished porting all of the architectures to M2-Planet/mescc-tools/stage0

<stikonas>unfortunately for now bootstrap in most architectures would stop after stage0-posix...

<stikonas>both mescc and tcc support limitted number of arches

<stikonas>even if gtker manages to skip mescc... It will still be limited to whatever tcc supports

<oriansj>stikonas: well, I figure it'll be fun to learn the encoding and ugly details of those architectures.

<fossy>Dor Askayo: the improve/merged_usr.sh script is *supposed* to do the sbin->bin and /usr->/ merges

<fossy>unfortunately it appears util-linux does install into sbin/

<fossy>that should be fixed

<fossy>we haven't really done any "meta" packages before, is there some reason that would be preferable over a script that creates them?

<fossy>stikonas: mes rebuild doesn't seem to have huge effect on CI, is 1 min slower, but that is run-to-run variation for GitHub runners (~3%)

<fossy>I'm happy with it even from the standpoint of reduced codebase

<fossy>CI has passed where this pr touches, i'll merge it

<fossy>Dor Askayo: what did you run to get python acting that way? python3 works fine for me with ./rootfs.py -bw --arch x86 --build-kernels --cores 8 --external-sources --interactive

<matrix_bridge><Dor Askayo> I guess it depends on how live-bootstrap's packages are expected to be used to create a functional system.

<matrix_bridge>If the expectation is that packages could be hosted somewhere and then downloaded and extracted into a directory which then becomes the root of a system, then having a sort of "filesystem" package would make sense.

<matrix_bridge>If packages are not meant to create a fully functioning system on their own or are provided only as building blocks for people to figure out by themselves how to use them, then perhaps such a package is not required.

<fossy>that is a good point, and one that i don't have an answer to right now

<fossy>originally they were intended as purely building blocks (e.g. why we statically linked everything)

<fossy>but i'm not sure that's actually the best path forward

<fossy>from your perspective as a "consumer" of l-b, what do you want/need?

<matrix_bridge><Dor Askayo> I would prefer a package, both for simplicity and for completeness. Having a package means that consumers don't need to figure out how to set up a complete and functioning system on their own, which makes it easier use of the project.

<matrix_bridge>In addition, l-b's extracted packages currently do not form a whole and functioning system, simply because it is missing a few directories and symlinks. I have shown an example here where dynamic loading is broken because none of the packages create the "/lib->usr/lib" symlink.

<matrix_bridge>In other words, existing packages (in my example the "python" package) have expectations that are not satisfied by any other package, and this feels incomplete.

<matrix_bridge><Dor Askayo> easier to use the project*

<fossy>hmmmmm, that is very fair

<fossy>i think we can faciliatate that on the l-b end

<fossy>facilitate*

<oriansj>l

<oriansj>sorry (cat attack)

<matrix_bridge><gtker> oriansj: From what I can tell it won't be possible to implement variadic functions with the current calling convention (at least for x86/x64), do you have a preference for how to solve this issue?

<oriansj>well variadic arguments are just an array and an array size

<oriansj>and va_arg() just takes the array and the index

<oriansj>(correction type not index)

<oriansj>so, if we moved all the local variable setup to the start of the function; we probably could do something like define a struct __VARIADIC__ with length, index and the array of the type being used in the vag_arg() call and throw an error if that function fails to do so

<oriansj>(using https://godbolt.org/ to get a couple ideas for how to implement it)

<oriansj>put the definition in stdarg.h

<oriansj>but we would have to first make the function call logic smarter

<oriansj>say add basic type checking where if the types passed are the same as the types expected by the function

<oriansj>then we can add logic that would notice the ... and do the creation of the struct on the stack and then we wouldn't need any more complexity in our changes

<oriansj>so yeah if you could just add basic type checking into the function call logic; it wouldn't be too difficult for me to add variadic function support

<oriansj>what do you think gtker?

<matrix_bridge><gtker> Initially I was just going to have "va_start" load the stack pointer into a variable and then increment that depending on the type, but I'm running into the problem that the stack pointer starts "before" adding the parameters, if that makes sense. And when loading local variables we index into the stack pointer based on the expectation that the parameters take up a certain size

<matrix_bridge><gtker> So if you push another parameter you'll end up pushing the local variables 4/8 bytes more than they're expecting, if that makes sense

<matrix_bridge><gtker> I initially assumed that (for x86/64) it worked like the x86 https://en.wikipedia.org/wiki/X86_calling_conventions#cdecl cdecl calling convention, except that paramters aren't passed in reverse order

<matrix_bridge><gtker> Where the first 2 instructions after calling a function are push the base pointer and move the stack pointer into the base pointer, so that you could index into the parameters by adding to the base pointer and into the locals by subtracting from it

<matrix_bridge><gtker> But M2-Planet does the function initialization before calling the function. So ```void f(int a) {

<matrix_bridge>}

<matrix_bridge>int main() {

<matrix_bridge>f(1);

<matrix_bridge>}

<matrix_bridge>"becomes":FUNCTION_f

<matrix_bridge>ret

<matrix_bridge>Defining function main

<matrix_bridge>:FUNCTION_main

<matrix_bridge>push_rdi # Prevent overwriting in recursion

<matrix_bridge>push_rbp # Protect the old base pointer

<matrix_bridge>mov_rdi,rsp # Copy new base pointer

<matrix_bridge>mov_rax, %1

<matrix_bridge>push_rax #_process_expression1

<matrix_bridge>mov_rbp,rdi

<matrix_bridge>call %FUNCTION_f

<matrix_bridge>pop_rbx # _process_expression_locals

<matrix_bridge>pop_rbp # Restore old base pointer

<matrix_bridge>pop_rdi # Prevent overwrite

<matrix_bridge>mov_rax, %0

<matrix_bridge>ret```

<matrix_bridge><gtker> Hope that came out readable

<oriansj>that is fine

<oriansj>think of each variadic function as having an implicit global struct

<oriansj>(or implict struct on the stack)

<matrix_bridge><gtker> Ah, OK, that makes sense. And then instead of pushing extra variables to the stack we push it to that global object?

<oriansj>bingo

<oriansj>it'll mean that doing recursive variadic functions will be broken but what sort of insane software would do that?

<matrix_bridge><gtker> I can live with it being broken as long as it works initially

<oriansj>and at compile time we will know the max number of arguments passed and we can allocate for the global statically

<oriansj>1 per each variadic function

<matrix_bridge><gtker> I was thinking just a global array of 1kb or so that's used for all of them since we can't be multithreaded?

<oriansj>well, I would advice to know the number of arguments passed to each of the functions and allocate specificly for each function just in case someone writes a variadic function that calls printf

<oriansj>^advice^advise^

<matrix_bridge><gtker> Hmm, yeah, that's true

<oriansj>and just track that information in a global struct list and build it all at the end

<matrix_bridge><cosinusoidally> fossy: out of interest was there a reason you stopped working on https://github.com/fosslinux/boteicc/ (a port of chibicc to the M2-Planet dialect)? Was that approach a dead end? I ask as I've recently started experimenting with chibicc, and a stock chibicc can build tcc.

<matrix_bridge><cosinusoidally> though a stock chibicc only supports outputting amd64 gas assembly

IRC channel logs

2025-02-28.log