<oriansj>well GeDaMo; it appears even making an edit, doesn't remove the warning. unless it is on some delay?? <stikonas>it might be that "wiki is active" criterion is more than one edit <oriansj>as I have made an edit to the stage0 page to include the boot0 subset of hex0 <oriansj>well I added several commits (and even a page for live-bootstrap) <oriansj>so just in case, I'll just clone it and if they take it down we can host it else where. <stikonas>live-bootstrap page will probably get out of sync with readme.md though :( <stikonas>but maybe it will at least stop wiki from being closed <oriansj>stikonas: fair but it is just an attempt to clear out the warning <stikonas>anyway, it looks like it's not just number of commits <oriansj>also the stage0 information is a bit behind with the M2-Mesoplanet work and related changes <stikonas>hmm, I still don't know what's wrong with M2-Mesoplanet on riscv32... <stikonas>probably not, riscv32 is not easy to get <oriansj>well there is the lack of wait or wait4 so I probably could have gotten that code very wrong <stikonas>but other arches seem to work with M2-Mesoplanet <oriansj>yes you did, I also appear to have written a local commit that I never upstreamed. <stikonas>anyway, to reproduce that issue it was enough to just run mescc-tools-extra kaem script <stikonas>(which is a much faster than building the whole stage0-posix) <stikonas>btw, this is the command I'm running ARCH=riscv32 BINDIR=$PWD/../riscv32/bin TOOLS=$BINDIR M2LIBC=../M2libc/ ../riscv32/bin/kaem -f mescc-tools-extra.kaem <oriansj>good thing doing b FUNCTION_waitid will work perfectly everytime and we can check our assumptions about what registers should be (specifically the return value and then the status) ***janneke_ is now known as janneke
<stikonas>oriansj: hmm, I have now retested with your patch again, and I think I'm getting failures every time now <stikonas> /home/andrius/repositories/bootstrap/stage0-posix/mescc-tools-extra/../riscv32/bin/M2-Planet abnormal termination, signal number = 36 <bauen1>stikonas: why do you need actual rv32g hardware, isn't qemu good enough ? <stikonas[m]>bauen1: qemu has limitations which causes some bugs in stage0-posix <bauen1>stikonas[m]: i think i still have access to a SiFive HiFive 1 from the university for another project, so i could ask if i could use it for some debugging for this, but that will be after my exams, so you'd have to remind me in a month or so <muurkha>yes, rv32 is pretty much only microcontrollers ***ChanServ sets mode: +o rekado
<rekado>to verify the strategy I built nhc98 with generated .hc files and then tried to use it as a Haskell compiler for GHC 4.08.2 <rekado>the GHC build system passes a lot of non-standard options to the Haskell compiler; after removing them we still have to deal with all the non-standard code… <rekado>the very first file it is supposed to compile contains this line: argv = unpackArgv ``prog_argv'' (``prog_argc''::Int) <rekado>I think these quotes indicate that these values are defined in the RTS <rekado>but obviously that’s non-standard and so nhc98 doesn’t know what to do with them. <rekado>a couple more files contain these quotes, seemingly to embed raw C code in Haskell. <rekado>GHC 0.29 only uses this syntax in one file for NULL and stderr <rekado>so… this means that the only way around this is by using GHC’s RTS, and this means using STGHugs. <Hagfish>is the non-standard code something that some clever automated rewriting would solve? <Hagfish>(that starts to get hard to reason about from an auditability point of view, but it sounds like an interesting idea at least) ***ChanServ sets mode: +o janneke