Refining decompilation of PIC code

[rgov]

I'm playing with a firmware written for an 8-bit PIC-18 microcontroller. This is my first time working with that architecture. I do have source for the firmware, possibly from a slightly different version.

The C source code goes:

if ((sys_time % 100) < 1) {
    ...
}

Expand disassembly listing for the relevant code.

     CODE:012cde dd c1 76 f0     MOVFF      LONG_DATA_01dd,LONG_DATA_0076                    = ??
     CODE:012ce2 de c1 77 f0     MOVFF      LONG_DATA_01dd+1,LONG_DATA_0076+1
     CODE:012ce6 df c1 78 f0     MOVFF      LONG_DATA_01dd+2,LONG_DATA_0076+2
     CODE:012cea e0 c1 79 f0     MOVFF      LONG_DATA_01dd+3,LONG_DATA_0076+3
     CODE:012cee 64 0e           MOVLW      #0x64
     CODE:012cf0 00 01           MOVLB      #0x0
     CODE:012cf2 7a 6f           MOVWF      0x7a,BANKED
     CODE:012cf4 00 0e           MOVLW      #0x0
     CODE:012cf6 7b 6f           MOVWF      0x7b,BANKED
     CODE:012cf8 00 0e           MOVLW      #0x0
     CODE:012cfa 7c 6f           MOVWF      0x7c,BANKED
     CODE:012cfc 00 0e           MOVLW      #0x0
     CODE:012cfe 7d 6f           MOVWF      0x7d,BANKED
     CODE:012d00 86 ec bb f0     CALL       __llmod,0x0=>local_0                             ulong __llmod(ulong dividend, ul
     CODE:012d04 00 01           MOVLB      #0x0
     CODE:012d06 76 51           MOVF       0x76,w,BANKED
     CODE:012d08 77 11           IORWF      0x77,w,BANKED
     CODE:012d0a 78 11           IORWF      0x78,w,BANKED
     CODE:012d0c 79 11           IORWF      0x79,w,BANKED
     CODE:012d0e d8 a4           BTFSS      STATUS=>STATUS,#Z,ACCESS                         = ??
     CODE:012d10 16 d0           BRA        LAB_CODE_012d3e

The original Ghidra pseudocode looks like this:

DAT_DATA_0076 = DAT_DATA_01dd;
DAT_DATA_0077 = DAT_DATA_01de;
DAT_DATA_0078 = DAT_DATA_01df;
DAT_DATA_0079 = DAT_DATA_01e0;
DAT_DATA_007a = 100;
DAT_DATA_007b = 0;
DAT_DATA_007c = 0;
DAT_DATA_007d = 0;
__llmod();
if ((DAT_DATA_0079 | DAT_DATA_0078 | DAT_DATA_0077 | DAT_DATA_0076) == 0) {
    ...
}

I'd like to improve the decompilation by teaching it that DAT_DATA_0076 is the 32-bit dividend/result and DAT_DATA_007a is the 32-bit divisor. I.e., I would like:

ULONG_DATA_0076 = ULONG_DATA_01dd;
ULONG_DATA_007a = 100;
ULONG_DATA_0076 = __llmod(ULONG_DATA_0076,ULONG_DATA_007a);
if (ULONG_DATA_0076 == 0) {
    ...
}

---

The function signature of __llmod is unsigned long int __llmod(unsigned long int dividend, unsigned long int divisor). I tried inputting this into the function editor like so:

Then I modified the types of DAT_DATA_0076, DAT_DATA_007a, and DAT_DATA_01dd to be ulong.

However, the pseudocode is now messier:

ULONG_DATA_0076 =
     CONCAT13(ULONG_DATA_01dd._3_1_,
              CONCAT12(ULONG_DATA_01dd._2_1_,
                       CONCAT11(ULONG_DATA_01dd._1_1_,(byte)ULONG_DATA_01dd)));
              /* WARNING: Ignoring partial resolution of indirect */
ULONG_DATA_007a._0_1_ = 100;
              /* WARNING: Ignoring partial resolution of indirect */
ULONG_DATA_007a._1_1_ = 0;
              /* WARNING: Ignoring partial resolution of indirect */
ULONG_DATA_007a._2_1_ = 0;
              /* WARNING: Ignoring partial resolution of indirect */
ULONG_DATA_007a._3_1_ = 0;
ULONG_DATA_0076 = __llmod(ULONG_DATA_0076,ULONG_DATA_007a);
if ((ULONG_DATA_0076._3_1_ |
    ULONG_DATA_0076._2_1_ | ULONG_DATA_0076._1_1_ | (byte)ULONG_DATA_0076) == 0) {
    ...
}

Playing around, I also tried turning these into unions of uint32_t and uint8_t[4]. Strangely it then produced pseudocode that copies the bytes out of order from what the assembly actually does?

UNION_dumb_union_DATA_0076.uchar[1] = UNION_dumb_union_DATA_01dd.uchar[1];
UNION_dumb_union_DATA_0076.uchar[0] = UNION_dumb_union_DATA_01dd.uchar[0];
UNION_dumb_union_DATA_0076.uchar[2] = UNION_dumb_union_DATA_01dd.uchar[2];
UNION_dumb_union_DATA_0076.uchar[3] = UNION_dumb_union_DATA_01dd.uchar[3]

[astrelsky]

Try creating a call fixup for __llmod and see if it makes it better or worse. The call fixup will basically replace the call to the function with what it does so it can display c = a % b; instead (assuming my assumption for what __llmod does is correct)

[Wall-AF]

Maybe the function __llmod is actually ldiv_t ldiv (long numer, long denom) or a ulong version!?!

[astrelsky]

Maybe the function __llmod is actually ldiv_t ldiv (long numer, long denom) or a ulong version!?!

No, it is a compiler generated function for the following:

// unsigned long int __llmod(unsigned long int dividend, unsigned long int divisor)
unsigned long int dividend; // assume properly initialized
unsigned long int divisor; // assume properly initialized

unsigned long int remainder = dividend % divisor;

The architecture either doesn't have the instructions to do this or it is very inefficient. The compile has created a function to do this automatically where necessary.