<Hagfish>i'm wondering, as you're updating README.md, is it worth also adding some indentation to the "containing" entries? <Hagfish>that might pollute the diff a little, and i'm not sure how nice/possible that is in markdown, but it's just something that came to mind when having a look through the PR <oriansj>gbrlwck: yes all assembly used by M2-Planet and MesCC is done in the M1 macro assembly <oriansj>that is why MesCC porting to a new architecture is very dependent on mescc-tools support of that architecture. <oriansj>One thing to note is that MesCC and M2-Planet never harmonized on M1 DEFINEs which is one of the reasons for the seperation between MesCC libc and M2libc <oriansj>gbrlwck: to be absolutely precise there are only a few things that need to be changed in mes-m2 to enable building for additional architectures. <oriansj>short version is there are only a few things in the the mes-m2 lib/ folder that need inclusion in M2libc but once that is done mes.c is then officially ported to *ALL* architectures supported by M2libc. It isn't hard work, just kind of tedious (walk down list of functions, check if in M2libc yet and port over if not; making each a seperate commit) ***nckx_ is now known as nckx
***verx_ is now known as verx
***robin_ is now known as robin
<gbrlwck>i'm kinda having issues wrapping my head around the next steps... should _exit() and _write() in mes-m2/lib/linux/riscv64-mes-m2/mini.c simply asm("li_____%a7,SYS_write") as defined at the very bottom of mes/lib/riscv64-mes/riscv64.M1 ? <gbrlwck>am i guessing right that i don't have to move the command arguments anywhere since the arguments are already where they should be (registers a0..aX)? <gbrlwck>when running kaem-riscv64.run in https://github.com/gbrlwck/mes-m2 i get "lib/linux/brk.c:29:SYS_brk is not a defined symbol" though it is defined? and the file defining it (include/linux/riscv64/syscall.h) is included via -f before lib/linux/brk.c ...? <gbrlwck>(btw thanks for all the replies -- i skim the logs before coming back here) <Hagfish>top comment mentions Bootstrappable Builds <Hagfish>(you may need to configure your account to show dead comments if you want the rely spicy takes, though) <stikonas[m]>gbrlwck: no, asm("li___...") is not the right way now <stikonas[m]>I suggest using the same define file as in stage0-posix <stikonas[m]>gbrlwck: maybe it's just better to start moving those required functions to M2libc? <stikonas[m]>although, personally, I find it a bit easier to write as in meslibc since assembly stuff is mostly hidden in syscall*() functions <stikonas>fossy: I've now updated stage0-posix in live-bootstrap <stikonas>maybe with aliases we can even undo tcc's -DONE_SOURCE (at least for slow mescc build) <stikonas>(whole tcc.c takes maybe 10 minutes to build without much output) <xentrac>there's a lot of really fascinating formal methods stuff going on now <fossy>10 minutes isn't too long, not sure if it's really useful, but we can see