IRC channel logs
2021-11-14.log
back to list of logs
<stikonas>and test0028 now passes on x86, amd64 and riscv64 (with new non-preprocessor code) <oriansj>stikonas: I'll start fuzzing mescc-tools tonight and hopefully clear out these sorts of bugs <stikonas>oriansj: and it accepts output from M2-Planet? <oriansj>can be used like so: execve_image ./test/results/test1000-knight-posix-binary --architecture x86 -f foo >| rom (use the rom image) <stikonas>argh, I need to build test0028 first for knight <oriansj>knight-native binaries can be just plain loaded in the knight vm as a rom file <oriansj>knight-posix requires --POSIX-MODE and execve_image to create a proper memory image <oriansj>as one needs to insert the argv and envp into the memory <oriansj>test1000 for knight will show exactly how to use it <oriansj>as I haven't yet figured out how to do something like qemu-userspace integration for knight binaries yet. <oriansj>I probably should update the makefile for stage0 to have a proper build target for execve_image <stikonas>ok, got division by 0 initially from vm, did one fix and now Computer Program has Halted after 108 instructions <oriansj>you can single step its execution if you would like, set a breakpoint or just check the exit code <stikonas>oriansj: I'll make M2libc PR first and then M2-Planet one that depends on it. But I guess you might want to first review the 2nd Pr <stikonas>oh already merged... Oh well, it's probably fine <stikonas>I'm still doing some final tests with the other PR <oriansj>although you might have made a mistake with 4089D9 <oriansj>as it would have only copied the bottom 32bits <stikonas>didn't pick this up in my tests as numbers were small <stikonas>thanks, let me pull it in, because test checksums will be affected <oriansj>and the bug fix for get_machine's segfault has been corrected <stikonas>I've reverted broken prefix ++/-- support for now in the first commit <stikonas>and 2nd commit fixes those compound assignments <stikonas>a bit unfortunate that I had to emit quite a lot of new assembly code <oriansj>just give me a little bit to review and I'll have it merged <stikonas>actually, I might have spotted one minor thing <stikonas>in knight-posix I should check for return code 0 <stikonas>line 56 in test/test0028/hello-knight-posix.sh <oriansj>vm in posix-mode does do a proper return codes <oriansj>you can verify it by simply having a LOADI R0 @15 and HALT <stikonas>well, I force-pushed into PR to fix this <stikonas>well, if you have any other comments, feel free not to merge yet and I'll fix the issues (probably tomorrow) <stikonas>it might be possible to use something like this for ++/-- too... <oriansj>well the knight output looks good to me <oriansj>but that is the simplest assembly syntax we do have <stikonas>but that might be because I did work quite a bit on it in stage0-posix <stikonas>and also because macros are made out of small independent tokens <stikonas>oriansj: one thing I should probably note, on x86/amd64 rax/rbx and eax/ebx are kind of swapped compared to other arches <stikonas>if you don't like that, I can make all of them more similar <stikonas>but I thought this would be fewest number of instructions <stikonas>normal arith_stub had something like XCHG_eax_ebx\nCDTQ\nDIVIDES_eax_by_ebx_into_eax <stikonas>so here it became DIVIDES_eax_by_ebx_into_eax <oriansj>well x86 is kinda ugly with division and modulus <stikonas>yeah, so I kind of simplified two xchanges of rax/rbx <oriansj>So I can understand the difference as it would harmonize the support instructions across the operators <oriansj>but the CDTQ does absolutely matter for signed division <oriansj>hence why for / and % there are signed and unsigned versions <oriansj>otherwise you will hit floating point exceptions and wonder WTF happened we don't use floating point <stikonas>because here I don't distinguish between signed and unsigned operations <stikonas>then I need to check what type is on the LHS <stikonas>it might still be useful if you could check for other issues <oriansj>for unsigned you have to load 0 into edx (rdx for amd64) <stikonas>yeah, I can see it in additive_expr_stub <oriansj>easy mistake to make, as one can go extremely far without noticing that difference <oriansj>(almost a year of M2-Planet use and development before janneke noticed it) <stikonas>well, at least I should be able to fix this <stikonas>we should have access to signed/unsigned info there <stikonas>I guess current_target->is_signed or something like that <stikonas>oriansj: should I actually combine all the duplicated strings from arith_stub and this new code? <stikonas>since those will be mostly or even exactly the same strings <stikonas>anyway, I'll continue working on this tomorrow <oriansj>you'll want to look at the use of promote_type to get the correct type behavior (matching the C standard) <oriansj>also a minor sanity check for arrays and struct members on atleast one architecture might be worth the effort <stikonas[m]>I checked arrays on amd64, but probably worth checking structs too <oriansj>I worry about it not working for a (foo+bar) += (baz + bart) case but that is something easy to validate <oriansj>stupid thought but your += code with a minor tweak would solve your ++ problem <oriansj>not the delayed addition behavior but it would do the addition and assignment <oriansj>so it would work for foo++ not that it could work for ++foo though <oriansj>but you probably wish to make that a seperate commit <oriansj>but also the sort of code case we could put as a known issue if it involves pointer arithmetic behaviors <ekaitz>stikonas: do you want to give it a try to riscv-32 bit? <ekaitz>I arranged an ELF header that I suppose it will work <ekaitz>I didn't compile the instructions or anything <ekaitz>but I need to setup the development environment for that and I don't have the energy for it :) <ekaitz>there's only to `ld`s you need to change <stikonas>but at least they don't matter for running things <stikonas>absolute label addresses, i.e. # :_start ; (0x0600078) <stikonas>ekaitz: hmm, I'm getting qemu-riscv32: ./hex0: Invalid ELF image for this architecture <ekaitz>i may forgot to change something <ekaitz>class is supposed to be 1 in 32 bits i think <ekaitz>give a try to this one and if it doesn't work i'll work on this on my own later in the afternoon <ekaitz>I gave this a short try and it doesn't look like it's failing <ekaitz>take please a look later and if it works we can start the riscv32 port! <stikonas>but might be due to something I messed up later <ekaitz>i just made an executable that exists and it worked <ekaitz>it might be related some other thingie <stikonas>let me update comments about addresses too <stikonas>yeah, I'm tweaking elf header a bit more to make same base address as elsewhere in stage0-posix but it's not quite easy to adjust <ekaitz>i just copied the header from x86... but maybe I missed something <ekaitz>i mean it should have the same base address <stikonas>well, at least in riscv I've used 0x600000 elsewhere <stikonas>but while checking those addresses I noticed riscv64 comments where a bit off <ekaitz>you know you don't have to do that now, right? :) <stikonas>oriansj: once you pull in bootstrap-seeds, I'll pull it into stage0-posix and update files there (hex0 + development/gas files) <stikonas>anyway, riscv32 port doesn't look like much work <stikonas>although, I'll probably be busy with M2-Planet <stikonas>ekaitz: so you can try to convert other files... <ekaitz>i'll spend some free time on it, sure <stikonas>basically in hex0 code header is 0x24 bytes shorter, so I subtracted that from comments. Then LD->LW means third hex number goes from 3 to 2 and same for SD->SW <stikonas>well, some immediates will need reencoding... <stikonas>but it will be mostly the same numbers over and over again <stikonas>although, immediates might now be easier for me, cause I've done enough of them to often know how to adjust it in hex directly without going to calculator <oriansj>stikonas: your riscv32 work has been merged. <oriansj>hopefully you remembered the zeroing patching Gabriel Wicki provided <stikonas>cause I took latest hex0_riscv64, took ekaitz header and replaced a couple of things <oriansj>I only ask because the merge indicated you were using an earlier commit <stikonas>anyway, I used latest stage0-posix commit <stikonas>and that's where that .hex0 file came from <stikonas>I've actually noticed minor issue in hex0_riscv64 comments <stikonas>although, it's only the difference between two offsets that matters <stikonas>anyway, ld->lw was the only functional change <stikonas>oriansj: I'm now running some more involved tests on assignments. Arrays and struct members seem to work. Although I am now hitting some other issue (possibly in the new type promote code)... <stikonas>i.e. state->p += CHUNK_SIZE; worked for me but <stikonas>(I'm using sha256sum for tests since it probably uses quite a bit of arithmetic and any small difference would quickly be apparent in hash mismatch) <stikonas>hmm, it doesn't seem to be type promotion... <oriansj>well type promotion function can only crash if it isn't given two types <stikonas>no, it might be mixed up assembly order with - operator <stikonas>at least that's what I'm reading from the M1 diff <oriansj>so not a compile time segfault but a runtime <oriansj>good, yeah that just means the generated assembly is wrong <oriansj>well yes, figuring out assembly is much easier than figuring out if a binary is doing the right thing. <stikonas>if it works then it means I'm almost done <oriansj>You might want to add a bootstrap-mode check, so that if any of these are used it'll throw an error on building <oriansj>It is the global variable: BOOTSTRAP_MODE <stikonas>well, basicaly so that we don't use this thing in M2-Planet itself <stikonas>since cc_* doesn't support any of this stuff <oriansj>so that in the future if someone tries to use the new functionality that cc_* doesn't support, it will be immediately caught by test1000 <stikonas>so I think it's just some messed up assembly for x86/amd64 <stikonas>maybe I shouldn't have swapped the registers there... <stikonas>well, I can undo it and use exactly the same strings as in arithmetic stub <oriansj>well the reason for the push in the general and arithmetic recursion is that the right side might alter the ebx (or r1) register setting up its value. Then the pop restores the left side before performing the operation <oriansj>but you'll know if you did it right with just a -= ((b * 37) >> 3 );