pcodetests

[mumbel]

Was looking at pcodetests to see if there was easy improvements there and at my old/previous pcodetest branch to see if i can get that updated/going again

One quick idea was increase optimizations, currently O0 and O3, but could also add O1, O2, Os, Og, Oz, and Ofast. At least for 32 BE MIPS and PowerPC none of these produced the same md5.

Only thing of note after a quick test:

ghidra/Ghidra/Extensions/SleighDevTools/pcodetest/c_src/BIOPS.test

Line 337 in 1ca9e32

ASSERTI1(u1_divide(U1_MAX, 1), U1_MAX);

This passed PPC O0, but failed Os, nothing wrong with SLEIGH, just copypasta maybe in test. Why return signed?

same looking issue here (again, why difference in signed/unsigned), but didnt fail junit:

ghidra/Ghidra/Extensions/SleighDevTools/pcodetest/c_src/BIOPS2.test

Line 379 in 1ca9e32

extern i2 u2_divide(i2 lhs, i2 rhs);

and I haven't messed with ARM pcodetest too much but did see this with grep:

ghidra/Ghidra/Extensions/SleighDevTools/pcodetest/c_src/arm/arm.test

Line 35 in 1ca9e32

ASSERTU1(i4_sbc(0, 0, 0), -1);

for the compilers, did ghidra team use crosstools-ng or anything. based on the "toolchain" args/config items these are at weird locations, so not a typical apt-get install gcc-powerpc type location. I guess this is the --sysroot?

[mumbel]

Can test.processors be run command line with gradle or other? I've always just right clicked run as->junit

[GhidorahRex]

I always run as junit as well

[GhidorahRex]

We have looked at using crosstools, and may pivot to that in the near future. And yes, for gcc we use --with-sysroot=(dir) (the actual directory isn't that important).

Those function definitions definitely need to be corrected. I can look into correcting those and re-running the tests.

[mumbel]

FWIW, I changed those and worked on random new tests and didn't really find any sleigh bugs in x86/MIPS/ppc/aarch/riscv64 (though some unimplemented riscv here when I changed some CFLAGS).

My only findings were probably related to rounding in floats which I mostly ignored and focused on immediates

[mumbel]

• Inc
• Dec
• All current BIOP operations with encoding a hardcoded immediate vs register (hopefully can copy paste this for more values... or r3,r3,r4 vs or r3,r3,1)
  Register shifting (i.e. have or r3,r3,r4, added or r3,r4,r5)
• 2s comp
• Maybe more, I forget, not looking at that branch ATM

Was gonna try detecting overflow/underflow but gave up on that after a quick glance.

[mumbel]

https://github.com/mumbel/ghidra/tree/pcode-tests

Added a few hundred tests, maybe in the thousand range, lots of redundancy trying to trick compiler into different instructions and register usage. still needs some rounding out in some of them, but finally got some results. Have not triaged. Looks like sparc has some issue with swap operations either in sleigh or gcc-ism as it passed on native, x86-32, PPC, MIPS, ARM, AARCH

                ASSERTU4(u4_swapRef(0x00000001), 0x01000000);
                ASSERTU4(u4_swapRef(I1_MAX), 0x7f000000);
                ASSERTU4(u4_swapRef(I2_MAX), 0xff7f0000);
                ASSERTU4(u4_swapRef(U1_MAX), 0xff000000);
          	ASSERTU4(u4_swapRef(U2_MAX), 0xffff0000);
                ASSERTU4(u4_swapRef(0x80000000), 0x00000080);
                ASSERTU4(u4_swapRef(0x00800000), 0x00008000);
                ASSERTU4(u4_swapRef(0x00008000), 0x00800000);
                ASSERTU4(u4_swapRef(0x00000080), 0x80000000);

		ASSERTI4(i4_swapRef(0x00000001), 0x01000000);
                ASSERTI4(i4_swapRef(I1_MAX), 0x7f000000);
                ASSERTI4(i4_swapRef(I1_MIN), 0x80ffffff);
                ASSERTI4(i4_swapRef(U1_MAX), 0xff000000);
                ASSERTI4(i4_swapRef(I2_MAX), 0xff7f0000);
                ASSERTI4(i4_swapRef(I2_MIN), 0x80ffff);
                ASSERTI4(i4_swapRef(U2_MAX), 0xffff0000);
                ASSERTI4(i4_swapRef(I4_MAX), 0xffffff7f);
                ASSERTI4(i4_swapRef(I4_MIN), 0x00000080);

i4 i4_swapRef(i4 val)
{
  i4 z;
  u1 *x = (u1 *)&val;
  z = (x[0] << 24) |
    (x[1] << 16) |
    (x[2] << 8) |
    (x[3] << 0);
  return z;
}
u4 u4_swapRef(u4 val)
{
  u4 z;
  u1 *x = (u1 *)&val;
  z = (x[0] << 24) |
    (x[1] << 16) |
    (x[2] << 8) |
    (x[3] << 0);
  return z;
}

[mumbel]

oh, duh. endian, guessing i didnt test with this on mips/ppc somehow. it doesnt look like pcodetest current has endian (reliably) at compile time

[GhidorahRex]

We could set a #define macro to get endianness, but otherwise it doesn't know.

[mumbel]

had 4 errors on 68000. 1 swap and 3 min/max (maybe new repro for #8396 or sleigh bug handling 64-bit math?)

#define PCODE_BIOP_MIN(typ)             \
typ typ##_minimumNew(                   \
                typ lhs,                \
                typ rhs)                \
{                                       \
        typ z;                          \
	z = lhs < rhs ? lhs : rhs;      \
        return z;                       \
} 

#define PCODE_BIOP_MAX(typ)             \
typ typ##_maximumNew(                   \
                typ lhs,                \
                typ rhs)                \
{                                       \
        typ z;                          \
	z = lhs > rhs ? lhs : rhs;      \
        return z;                       \
}                                 	\
typ typ##_maximum(                      \
                typ lhs,                \
                typ rhs)                \
{                                       \
        typ z;                          \
        z = lhs >= rhs ? lhs : rhs;     \
        return z;                       \
}


PCODE_BIOP_MIN(i8);
PCODE_BIOP_MAX(i8);

ASSERTI8(i8_minimumNew(1, I8_MIN), I8_MIN);
ASSERTI8(i8_maximumNew(1, I8_MIN), 1);
ASSERTI8(i8_maximum(I8_MIN, 1), 1);

[mumbel]

Yeah, realized that too after commenting, was gonna double check... Def didn't mean decompiler, but could/would sborrow be broken .. I also need to check how far behind my branch is

[mumbel]

I don't know 68000 at all.

Ignoring possible SBORROW issues. Two things that stuck out.

:subx.l Ty,Tx   is op=9 & op8=1 & op67=2 & op45=0 & Ty & Tx
{
        tmp0:4 = zext(XF);
        subxflags(Tx, Ty);
	local tmp = tmp0 + Ty;
	Tx = Tx - tmp;
	extendedResultFlags(Tx);
}

macro subxflags(op1,op2) {
 CF = (op1 < op2) || ( (XF == 1) && (op1 == op2) );
 VF = sborrow(op1,op2);
 XF = CF;
}

just checking op1 < op2 is or isn't op1 s< op2?

macro extendedResultFlags(result) {
  NF = result s< 0;
  ZF = (result == 0) && (ZF == 1);
}

Where does the ZF logic come from (currently it would be previous instructions)?

[mumbel]

well op1 s< op2 exploded the errors. and manual reads that yes ZF is supposed to just be previous instructions to chain.... which maybe leaves only the VF in the ble.b logic.

[GhidorahRex]

The manual states that ZF is cleared if the result is non-zero, otherwise unchanged. So that line matches. As for the carry flag, that one might be incorrect, but only for the second half. I think the (op1 < op2) part is actually correct because it matches the carry flag for the non-extended subtraction. I'll look into that.

[GhidorahRex]

Sorry, didn't see your comment while I was authoring mine. Yes, probably just VF in ble.b at most. I'll check it out