<stikonas>oriansj: I have #error working in M2-Planet now <stikonas>or maybe it would be better to properly fix mes <stikonas>rather than #if __i386__ I think it should be #ifdef SYS_waitpid <stikonas>janneke_: does this change sound reasonable? <stikonas>"#if __i386__" -> "#ifdef SYS_waitpid" ? <stikonas>than rather than hardcoding all arches, we can just go over the list of syscalls <stikonas>very similar to #define but actually simpler <stikonas>hmm, there are other places in mes where __i386__ is checked. So we probably need to deal with it in M2-Planet in any case ***Thalheim is now known as zv
<stikonas>ok, I might be able to add support for macro variables but need to do a bit more testing tomorrow <oriansj>stikonas: instead of adding host architecture detection to M2-Planet, just use -D __i386__=1 in the command arguments <oriansj>as it does support arbitrary number of -D statements=num <oriansj>I might even use it to remove the hand updating of version numbers in mescc-tools <oriansj>as for mkdir -p yeah just skipping over the -p will work just fine. <oriansj>for 2 reasons, it is only expected to work if the folder isn't there (which it will not be when bootstrapping) and if it is there, we just ignore the failure. <oriansj>stat requires 16bit fields if I remember correctly <oriansj>which means we would need to add proper 16bit field support to M2-Planet <janneke_>stikonas[m]: yes that makes sense. i guess many preprocessor directives need to be revisited once mes switches to an m2 version that doesn't treat them as comments ***janneke_ is now known as janneke
***Jeremy_Rand_ is now known as Jeremy_Rand
***stikonas_ is now known as stikonas
<gbrlwck>it's tested, works and does not add a dependency on stat syscall :) <gbrlwck>is pmatch part of mes? i can't find a reference to it in Guile Reference neither in my GUILE_LOAD_PATH.... <gbrlwck>is there any kind of reference or documentation on the (internal) workings of mescc? <stikonas>gbrlwck: and I'm not aware of any additional documentation <stikonas>gbrlwck: change looks good to me, but maybe you can use tab to indent i = 2; (and also the other create_dir line which you haven't touched but that line also had inconsistent indentation) <gbrlwck>something like: "we imitate GNU mkdir's "-p" argument because it's relied on in bootstrapping" ? <stikonas>something like that or maybe we immitate GNU mkdir's "-p" for compatibility reasons <gbrlwck>well, it's not *really* compatibility, since coreutils' `mkdir -p` would also create all the parent directories :) <gbrlwck>stikonas: i got mes-m2 to build correctly. my first `./bin/mes-m2 -c "(display 'hello) (newline)"` got stuck (nothing happened for a couple of minutes, strace showed nothing, so i aborted execution). <gbrlwck>so i started again, attached strace which showed tons of SYS_read calls (all for one character each), then this: <gbrlwck>clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=85, tv_nsec=123165000}) = 0 <gbrlwck>and rn the machine is not under stress <gbrlwck>have you managed to eliminate the segfault issue? <gbrlwck>time reports: (0major+2973minor)pagefaults <gbrlwck>4/4 runs succeeded, no segfaults on risc-v hardware <stikonas>hmm, those crashes might actually be qemu specific <stikonas>I think qemu only reserves 16 MB of space of brk purposes <stikonas>and expects normal apps to use malloc with mmap ***dekenevs is now known as kitzman
<stikonas>gbrlwck: if you don't have any segfaults, you can try using mescc to build mes (although, right now only mes for x86 as mescc is not ported to riscv\) <stikonas>well, we just do brk syscall to reserve memory <stikonas>not sure what's needed to avoid pagefaults <stikonas>I guess that's expected if you use brk rather than mmap <gbrlwck>do we allocate tiny memory regions with sys_brk? <gbrlwck>i'm trying to compile a tiny "return 42" c program with mescc; it's been running for ages... not sure if trying to compile mes with mescc is any fun at this stage <gbrlwck>btw i'm looking into the risc-v port of mescc but i'm not completely sure what things mean. i.e. "r2->r0" means load value from register 2 into register 0? <gbrlwck>stikonas: that's ok; i'll figure it out <stikonas>checkout out that branch in upstream mes <gbrlwck>but you do know about x86 M1, don't you? <stikonas>some often I can figure out x86 M1 but maybe not always <stikonas>anyway, I guess try to get mes faster first, maybe profile where most of the time is spent. Otherwise indeed mescc will be too slow to be fun <gbrlwck>it's no hurry for me: i can run mescc with guile <stikonas>I've ended up getting preprocessor variables working, it was actually fairly simple. So thing like #if __i386__ now work. No need to do #if defined(__i386__).