<stikonas>argh... lex is much harder to port away from wchar_t :( <fossy>anything in particular ur running into <stikonas>well, I have partial WIP commit that generates lex.yy.c but that one has some truncated strings (as with yacc) <stikonas>but I can't easily replace remaining wchars with chars <stikonas>because some functions don't work with them <stikonas>this needs more thinking than blindly replacing... <stikonas>but in any case, I"ll look more some other day <fossy>what is wrong with just making that function take a char <deesix>OriansJ, how can I run the Knight binaries during M2-Planet testing? I guess one part is to override the arch, then configure something for the system to recognize the binaries and use the VM in stage0, maybe? Do you have any script/doc about this procedure? <OriansJ>deesix: well the knight native binaries are the most simple to test, Simply vm --rom binary --tape_01 input --tape_02 output <deesix>hmm, but that's not what the scripts are doing, right? How do you glue it all? <OriansJ>deesix: I've just been manually running them <deesix>So lines like... ./test/results/test0006-knight-native-binary >| test/test0006/proof || exit 4 <OriansJ>test0000 for example is just vm --rom ./test/results/test0000-knight-native-binary && echo $? <OriansJ>become vm --rom ./test/results/test0006-knight-native-binary --tape_02 test/test0006/proof <deesix>Any reason not to call the vm from the scripts? <OriansJ>deesix: well we wouldn't want to try to run the vm if the stage0 vm isn't installed as it would result in failing tests <OriansJ>but as knight-native isn't something uname or get_machine is ever going to actually return without an override, it wouldn't be a problem to do that. <OriansJ>knight-posix however is a bit more complicated <OriansJ>as you need more than stage0's vm built <deesix>I think I leave Knight out of the unification for a while. <OriansJ>as you need execve_image.c built too but after that it is actually quite similiar <deesix>... as M2libc migration is not complete and this other situation about running binaries. <OriansJ>as you need to convert the binary into a program image with argc, argv and envp included for loading into Memory prior to execution. <OriansJ>just gcc High_level_prototypes/execve_image.c -o bin/execve_image and you have it <OriansJ>then you would use it like this: execve_image test/results/test1000-knight-posix-binary --architecture x86 -f test/common_x86/functions/file.c -f test/common_x86/functions/malloc.c -f functions/calloc.c >| memory_image <OriansJ>and then just vm --POSIX-MODE --rom memory_image --memory 2M <OriansJ>I guess it is just another mess for me to clean up <deesix>OriansJ, thanks for the details. I'll keep them in mind and maybe some way to plug it all arises. <deesix>Manually running them doesn't seems fun, for sure. <OriansJ>well knight-native will always be pure bare metal knight. knight-posix should exist in a few years and thus I'll probably make an environmental variable which if set would enable that testing <OriansJ>plus other people probably would want to test knight without having to do all the manual work too. <OriansJ>So just gotta find time to do the work. <OriansJ>but first I need to get guix pull to work on my new build server. <deesix>Yes, I found a couple of details missing in the knight-posix migration and though about fixing them and so a run check. But I guess I can patch and just let the sha cover the situation. <OriansJ>deesix: well a couple of the knight HALCODE calls haven't been implemented in the knight vm yet like fork and waitpid <OriansJ>fortunately, that doesn't matter because known of the knight posix tests depend upon them yet <OriansJ>fortunately knight vm doesn't care about undefined instructions that it doesn't have to run. <OriansJ>the disassembler might bitch that it is data but it will not prevent people from doing development and testing. <OriansJ>for the sake of simplicity and convention, knight-posix shares ALL Linux call numbers with AMD64; the difference being instead of putting the number in RAX, it is in the instruction itself eg 0x42000001 is sys_write and 0x42000002 is sys_open, etc. with the arguments passed in R0-R6 with the results returned in R0-R3 respectively. <OriansJ>mostly to make polymorphic syscalls impossible in R-X memory as that is a horrifying idea in bootstrapping audit. <stikonas>fossy: so after a bit more investigation, I think instead of patching lex we should fix mes libc <stikonas>I have a small reproducer for that bug, just need find out what causes it ***malina is now known as ``````````
***`````````` is now known as ``^``-``^``
<stikonas>when it encounters multibyte wchar_t, it finds 0 quicker than end of string <stikonas>probably not easy to fix either because it's correct for char... Unless we implement whole wchar in mes libc... <deesix>stikonas, is wchar still defined as char? (I think I read about this some days ago here). <deesix>Because, indeed, I can imagine every other byte being zero and the string truncated to one letter. <stikonas>I can add some hack, that fixes strlen if input is multibyte... <deesix>I guess it's around the 18th in the logs. <stikonas>yeah, but I don't think we can define wchar as char in lex... <stikonas>but I think lex functions expect multibyte <stikonas>ok, I think in the end I'll patch lex... <stikonas>fossy: ok, I think I've got lex working now... <stikonas>now need to test, prepare PR and then do flex 2.5.1...