IRC channel logs
2025-04-04.log
back to list of logs
<matrix_bridge><gtker> Stikpnas: Can we automate that in some way so that they just always run during make test? <fossy>stikonas: oh dear, mpfr rebuild causing ICE was not on my cards <stikonas>gtker: hmm, they are not currently compiling, so one would have to make expected failure testcases... <stikonas>in fact it seems that currently there are issues even in stage0-posix, I'll try to take a look <stikonas>with M2-Planet from Tuesday aarch64 binaries seems to crash <stikonas>and updating further to yesterdays M2-Planet seem to cause even more issues :( <stikonas>as for M2libc, maybe I'll try some files by hand and try to create more targeted reproducers <matrix_bridge><Andrius Štikonas> gtker: aarch64. I've started bisecting but right now I'm outside, will continue when I'm back <matrix_bridge><gtker> stikonas: I believe there's something wrong with the new "LOAD_W13/14/15_AHEAD" opcodes. At the very least "LOAD_W14_AHEAD" should probably be "2e000098" instead of "e2000098" <matrix_bridge><Andrius Štikonas> gtker: there is also some unrelated problem on all arches with yesterday's changes <matrix_bridge><gtker> I'm working on getting aarch64 to pass the M2-Planet tests, what other failures are there? <matrix_bridge><Andrius Štikonas> Hmm, don't remember on top of my head but if you pull on latest M2-Planet submodule into stage0-posix then make test-x86 crashes <matrix_bridge><Andrius Štikonas> And aarch64 crash is already in stage0-posix... <stikonas>gtker: so I'm back now, have you found out anything about aarch64? <stikonas>git bisect shows 4fcd9e43134ea126d9750a54eaa8b143a3b0ad18 Use REGISTER_EMIT_TEMP as temp instead of REGISTER_ONE in emits <matrix_bridge><gtker> stikonas: At least one of the issues is that when we're calculating the load relative to a register we're subtracting X1 from X14 (temp register), which means our address goes negative <matrix_bridge><gtker> Another issue may have been that the "LOAD_W13_AHEAD" loaded into the x13 register instead of w13 like "LOAD_W1_AHEAD". Strangely though the "LOAD_W0_AHEAD" uses the x0 form for some reason, and that seems to work <matrix_bridge><gtker> After fixing the negative address calculation I've got a repro of ` <matrix_bridge><gtker> It seems to have something to do with there being a specific amount of locals/parameters that messes something up on the stack, since popping the saved variables after a function calls gets the wrong values <matrix_bridge><gtker> stikonas, oriansj: I may have also made a mistake on the direction of the stack on aarch64, does it grow by addition or subtraction? <matrix_bridge><gtker> OK, so that's probably at least one of the problems that we're having <matrix_bridge><gtker> As a minimal repro after fixing the stack direction, just including <stdio.h> fails. This is usually the most minimal initial repro since it includes a whole lot of code 😄 <matrix_bridge><gtker> I'm still getting segfaults in malloc with a #include <stdio.h> repro, so it's not fully functional yet. Investigating further <matrix_bridge><gtker> "int main() { int a; a; }" fails. It seems to do with variable loading <matrix_bridge><gtker> Figured it out. It's because the depth is negative while we're emit_subbing for aarch64. Still fails though. I'll push the fix to my master <deesix>IIRC, LOAD_W0_AHEAD uses a form of x0 because we required to sign-extend the full register. <deesix>As for the kind of stack, the HACKING file should confirm what was the expectation (at least at that time), I think. <stikonas>aarch64 would benefit from word style rework... <stikonas>it's really nice not to need to deal with new M1 defines for risc-v <matrix_bridge><gtker> stikonas: Sure, I've got tests passing up to 0031, which seems to either infinite loop or it's just really slow <stikonas>let me try to test a bit and see what happens <matrix_bridge><gtker> I've thought the same while adding the new defines. It's a massive pain but I don't think we can do it because of the endianness <stikonas>well, we need to fix all those issues before any further feature development I think... <matrix_bridge><gtker> stikonas: I need an "abs" function for it to work. Any idea how to do it in a cc_* friendly way? <matrix_bridge><gtker> stikonas: My current master hangs on 0031. I believe that I have fixed the stack direction weirdness <matrix_bridge><gtker> stikonas: Switches seem broken on aarch64. Repro "int main() { switch(2) { case 2: return 122; default: return 0; } }" fails but works on amd64 <stikonas>ok, they have LOAD_W16_AHEAD\nSKIP_32_DATA\n&_SWITCH_TABLE_ <stikonas>ok, latest M2-Planet / M2libc does seem to work on x86 <matrix_bridge><gtker> Stepping through it in gdb it seems the "b" (SKIP_INST_NE?) instruction just doesn't jump? <matrix_bridge><gtker> It seems like the "SKIP_INST_NE" does just ahead of the "BR_X16" which jumps back to the beginning of the "_SWITCH_TABLE" <matrix_bridge><gtker> Image might not show on IRC. The instructions marked with blue should jump to one instruction after the "br x16", but just don't? <matrix_bridge><gtker> stikonas: 0031 seems to be the only failing test for aarch64 now. Commenting it out shows all others passing <matrix_bridge><Andrius Štikonas> ok, I went to matrix, I can see the image <matrix_bridge><gtker> stikonas: I updated my branch with proper test results. I'm going to go sleep soon, do you want me to make a PR? <stikonas>yeah, ok, I'll take a look while you sleep <deesix>Maybe I'm some commits behind but, yeah... "CMP_X1_X0\nSKIP_32_DATA\n&_SWITCH_CASE_" does not make a lot of sense. Compare is a bit more involved; also, nothing is doing the load (LOAD_W16_AHEAD). <stikonas>switch was probably not very well tested before <stikonas>so it migth have always been broken on aarch64 <deesix>Hmm, maybe this situation does not require much cmp dance, but I guess it's better to move it a few lines down (just before the skip+br) and put the load there instead. This is me not really reading it all, but thit feels more sane. <deesix>Like "LOAD_W16_AHEAD\nSKIP_32_DATA\n&_SWITCH_CASE_" and then "\nCMP_X1_X0\nSKIP_INST_NE\nBR_X16\n", if that makes sense. <deesix>^ That's for the /* create the table */ section. <deesix>The /* Default to :default */ section also feels wrong, lacking the load before the data. <deesix>For reference, I'm looking at 46026e6b3700 (just in case something changed there, recently).