<stikonas>it should add support to stuff like *a instead of having to use a[0] <stikonas>hmm, although I think it only implements things like a = *b but not *a = b <oriansj>stikonas: well *a isn't just a[0]; it is the FULL object so for a struct it might be a[0], a[1], a[2]...a[32] <oriansj>*a = *b is the full copying of an object <stikonas>well, I might be able to fix it but it needs more thought... <oriansj>well it is only used in mes.c garbage collection <oriansj>so maybe we can convince janneke to remove its use from master <stikonas>but was mostly thinking about char* arrays... <oriansj>and multi-dimensional array test is now test0026 in M2-Planet <oriansj>and the 24 fuzz run has found 8 new unique crashes; so I'll debug and add some requires to catch them <stikonas>hmm 8 is quite a lot :(. But on the other hand, we do have quite a bit more of functionality <oriansj>actually 8 isn't bad at all for 24hours of fuzzing, it means only 1-2 places that need input validation <oriansj>trust me, when I started fuzzing 6K unique crashes in 30 seconds were not uncommon <oriansj>in this case, it only requires a single if(null == token) exception block <stikonas>hmm, my PR actually does seem to work on the right hand side of equality... <stikonas>yeah, but maybe will finish the rest before pushing <oriansj>and solution for existing fuzz crashes up <oriansj>I'll start fuzzing the latest code paths <oriansj>(pointer happy code concerns me heavily when doing audits) <gbrlwck>what makes 'include/mes/macros.h' tricky (mentioned here by stikons 2 days ago)? isn't preprocessing mostly just (literal) text replacement? <stikonas>gbrlwck: it's two things there, one is preprocessing (so somebody has to implement more advanced text replacement than what we have right now) <stikonas>and the other thing that needs implementing is '.' operator for struct members ***wowaname is now known as opal
<stikonas>but it would probably need more code than some other features <stikonas>so far, a lot of other features needed fairly small changes <stikonas>having M2-Planet tests does make it less tricky, but maybe we first need to add more tests that check existing macro functionality <oriansj>well yes, it is best to add a test for behavior after adding that feature into M2-Planet, so that regressions are much more quickly found <oriansj>perhaps test driven development might be something worth investing in M2-Planet <stikonas>yes, perhaps I'll add tests too for that *s pointer feature <stikonas>and tests did help us to finish of cc_riscv64 and other risc-v stuff <stikonas>there were some minor issues before everything started working <stikonas>so basically here we need to somehow implement stuff those functions like #define A(x,y) x+y <stikonas>right now it's just litereal test replacement #define A a <gbrlwck>what raises hex2's "Target label _start is not valid" ? <stikonas>gbrlwck: _start is the label specified in ELF header, that's the first label where kernel will jump after creating new process <stikonas>we do a bit of argc/argv/envp preparation there, initialize stdout/stdin/stderr jump to main() and on return from main() call SYS_exit syscall <gbrlwck>neither repo "mes" nor repo "mes-m2" seem to have such a file <stikonas>mes-m2 has ./lib/linux/riscv64-mes-m2/crt1.M1 <gbrlwck>but i guess this /should/ be included automatically? <stikonas>it might be looking at riscv64-mes-mescc <stikonas>and contents might have to be a bit different <stikonas>different compiler might need somewhat different initialization <stikonas>(due to differences in calling convention) <stikonas>porting crt is one of the more annoying things, since it's mostly assembly <stikonas>so you have to understand compiler calling convention <stikonas>at least there are a few examples in other arches <gbrlwck>so i just have to port void longjump() and int setjmp() ? <gbrlwck>and by "compiler calling convention" you mean how we save register states on the stack? <stikonas>gbrlwck: indeed, that's how we save registers on the stack and how function arguments are passed <stikonas>gbrlwck: those longjump and setjmp are kind of ported but with different M1 defs file (that's before we got that . thing in mescc-tools) <gbrlwck>but shouldn't we use the M1defs file from M2libc? <stikonas>gbrlwck: M1defs file in M2libc is newer than that branch with attempted risc-v port of mes <gbrlwck>stikonas: exit-42 is just "RD_A0 !42 ADDI" ;) <stikonas>hnnm I'm trying to find where crt1 for mescc is <stikonas>so _start is in crt1.c although that's really and assembly file <stikonas>probably that's simpled with mescc than to specify an external assembly file like we did with M2-Planet <gbrlwck>stikonas: i didn't understand what you meant with your last statement <stikonas>I meant that's why mescc crt1 file is in .c file with inline assembly rather than in M1 file