IRC channel logs
2026-03-20.log
back to list of logs
<ArneBab>old: thank you for taking up lilypond (and windows) reviews! <old>ArneBab: pleasure! I want to get Windows up and working for next release <old>Once this is done, I would like it to stay that way (no regression) <ekaitz>btw who was the one that tried to execute fibers' tests and had a failure in riscv because of the JIT? <ekaitz>rlb: great, i'll try to take a look, thank you <ekaitz>rlb: should we open an issue in Guile or lightening? <ekaitz>rlb: but i don't see much information there, it's the guile tests? fibers? or what is it? i'm lost <rlb>It was causing the buildds to fail on guile-fibers, and I was trivially able to reproduce it on a porterbox by trying to building guile-fibers against guile with the jit enabled. <ekaitz>i have to take a look into that then to see what's going on <rlb>And wrt where we should have a bug/issue, not sure --- I guess if it's easy to figure out up front whether or not it's a lightening issue, then I'd put it there, otherwise, perhaps guile. <ekaitz>probably some memory barrier is poorly implemented, and lightening needs some test <rlb>And I imagine you saw, but it's not urgent since disabling the jit seems to work just fine. <rlb>If you're going to be working on it, do you already have a way to test riscv? <ekaitz>rlb: i have a riscv test setup because i worked on the riscv bootstrap <ekaitz>it's a very simple setup, but it might help <old>what seems to be the issue for RISC-V ? <old>Is the emitted code not valid (bug in lightning?) <old>Typically, RISC-V has no definition of XMC (Cross-Modifying-Code) in their spec. If the JIT code is emitted by thread A and execute by thread B, the only way to make it work is stop the world and full memory barrier across all CPUs <old>At least, that was the case from my last reading <rlb>I don't know --- all I know is that it was crashing (via segfault?). <rlb>and --enable-jit=no "fixed" it. <ekaitz>old: i don't know that much about RV, maybe you can help <ekaitz>old: the barriers are probably not great, I didn't know very well what I was doing when I made that <rlb>though that's just a guess <ekaitz>now I'm reading it, i don't even know how I managed to write it lol <ekaitz>if you guys could take a look, there's a comment on `mfence` <ekaitz>if that's right, probably we need to think about what old is saying and change higher level stuff, like putting barriers in a few locations <old>The proper protocol on Linux would be: Write the JIT; membarrier(2) with MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE; Publish jit code to to other threads <old>One problem could be also: <old>If the JIT allocate say, 16 bytes for a function. Then, it allocate a new 16 bytes for another function just after. <ekaitz>old: could you please open an issue in guile/lightening with that info? <old>The CPU is allowed to cache the instructions read-ahead when it executed the first 16-bytes, thus the next 16 bytes are cached and won't be invalidate by the write <old>sure, but I lack the details (log outputs and everything) <old>I could cerainlty just dump my knoweldge of XMC as an issue if you want <old>I had some note somehwere I could fetch also <ekaitz>only the two issues that rlb mentioned before <ekaitz>ACTION is swamped with other things now but will work on that <rlb>I think one of those bugs (they're clones) may have a link to the logs of the failures, if they're still available. <rlb>if that helps, though I iirc it may have just been a "segfault" line at the end. <ekaitz>yeah it was probably just that segfault <ekaitz>we should try to reproduce under the microscope hehe <old>defintelly need a segfault crash handler in Guile <old>with nice error reporting <ekaitz>ACTION is now working on a crazy segfault in GNU Mes <rlb>yeah, it was "easy" to provoke