Ghidra: How to avoid register renamed when declaring parameters (pass in register)

[simeonpilgrim]

So I have a health normal function for a processor module I've written for the Fujitsu FR (which is to say I very open to this being something my module code is doing wrong). But I have disassembly function that looks like:

                         **************************************************************
                         *                          FUNCTION                          *
                         **************************************************************
                         undefined FUN_0020ef3a(void)
                           assume tbr = 0xdfc00
         undefined         r4:1           <RETURN>
         byte              Stack[-0x11]:1 local_11
         byte              Stack[-0x12]:1 local_12
         byte              Stack[-0x14]:1 local_14
         byte              Stack[-0x16]:1 local_16
                         FUN_0020ef3a                                    XREF[3]:     Tsk1B:001099d4(*), 
                                                                                      Tsk1B:0010a2c2(*), 
                                                                                      FUN_001e6a06:001e6a34(*)  
    0020ef3a 8f c0           stm1       (r8, r9)
    0020ef3c 17 81           st         rp,@-r15
    0020ef3e 0f 03           enter      0xc
    0020ef40 8b 49           mov        r4,r9
    0020ef42 8b 58           mov        r5,r8
    0020ef44 8b e4           mov        r14,r4
    0020ef46 a5 e4           add2       -0x2,r4
    0020ef48 8b e5           mov        r14,r5
    0020ef4a 9f 8c 00        ldi:32     FUN_00344f64,r12
             34 4f 64
    0020ef50 9f 1c           call:D     @r12
    0020ef52 a5 f5           _add2      -0x1,r5
    0020ef54 6f e0           ldub       @(r14,0xfe),r0
    0020ef56 8b e5           mov        r14,r5
    0020ef58 5f d0           sth        r0,@(r14,-0x6 )
    0020ef5a 6f f0           ldub       @(r14,0xff),r0
    0020ef5c 8b 94           mov        r9,r4
    0020ef5e 5f e0           sth        r0,@(r14,-0x4 )
    0020ef60 a5 a5           add2       -0x6,r5
    0020ef62 d8 05           call:D     FUN_0020ef6e                                     undefined FUN_0020ef6e(void)
    0020ef64 8b 86           _mov       r8,r6
    0020ef66 9f 90           leave
    0020ef68 07 81           ld         @r15+,rp
    0020ef6a 8d 03           ldm1       (r8, r9)
    0020ef6c 97 20           ret

and decompiles like:

void FUN_0020ef3a(void)
{
  byte local_16;
  byte local_14;
  byte local_12;
  byte local_11;

  FUN_00344f64();
  FUN_0020ef6e();
  return;
}

if I alter the functions to say there are two parameters passed in r4,r5

side question 1: it defaults to 'use custom storage' (this might be because I imported this code from IDA where the function parameters where not decoded.. I'll so actually I'll ignore that for now, but that might come into play in the real question..

so I add two parameters to make the signature:

void FUN_0020ef3a (undefined param_1, undefined param_2

and the decompile looks nice.. BUT

now ALL uses of R4 or R5 in the function even when they are return code a renamed param_1 or what ever I call them in the decompiler.

                         **************************************************************
                         *                          FUNCTION                          *
                         **************************************************************
                         void __stdcall FUN_0020ef3a(undefined param_1, undefined
                           assume tbr = 0xdfc00
         void              <VOID>         <RETURN>
         undefined         r4:1           param_1
         undefined         r5:1           param_2
         byte              Stack[-0x11]:1 local_11
         byte              Stack[-0x12]:1 local_12
         byte              Stack[-0x14]:1 local_14
         byte              Stack[-0x16]:1 local_16
                         FUN_0020ef3a                                    XREF[3]:     Tsk1B:001099d4(*), 
                                                                                      Tsk1B:0010a2c2(*), 
                                                                                      FUN_001e6a06:001e6a34(*)  
    0020ef3a 8f c0           stm1       (r8, r9)
    0020ef3c 17 81           st         rp,@-r15
    0020ef3e 0f 03           enter      0xc
    0020ef40 8b 49           mov        param_1,r9
    0020ef42 8b 58           mov        param_2,r8
    0020ef44 8b e4           mov        r14,param_1
    0020ef46 a5 e4           add2       -0x2,param_1
    0020ef48 8b e5           mov        r14,param_2
    0020ef4a 9f 8c 00        ldi:32     FUN_00344f64,r12
             34 4f 64
    0020ef50 9f 1c           call:D     @r12
    0020ef52 a5 f5           _add2      -0x1,param_2
    0020ef54 6f e0           ldub       @(r14,0xfe),r0
    0020ef56 8b e5           mov        r14,param_2
    0020ef58 5f d0           sth        r0,@(r14,-0x6 )
    0020ef5a 6f f0           ldub       @(r14,0xff),r0
    0020ef5c 8b 94           mov        r9,param_1
    0020ef5e 5f e0           sth        r0,@(r14,-0x4 )
    0020ef60 a5 a5           add2       -0x6,param_2
    0020ef62 d8 05           call:D     FUN_0020ef6e                                     undefined FUN_0020ef6e(void)
    0020ef64 8b 86           _mov       r8,r6
    0020ef66 9f 90           leave
    0020ef68 07 81           ld         @r15+,rp
    0020ef6a 8d 03           ldm1       (r8, r9)
    0020ef6c 97 20           ret

Which is super frustrating when they get saved into another register/stack location, and the over written and it still labelled.

So my question is: how do I stop this from auto-magic happen. I would be ok with a way to "undo" the auto magic, but really on a 20MB firmware file that a non-starter.

[saruman9]

Answer 1: I started to fix this (#1493), but while PR was not merged I can't to continue works in this direction.
Answer 2: Edit ➡ Tool Options... ➡ Listing Fields ➡ Operands Field ➡ Markup Register Variable References.

[simeonpilgrim]

Ah... thank you so much for the answer to 2, and the insight on question one I will take and "just deal with", but 2 is a life saver!

[a33b]

The behavior in your example IMO is acceptable up to 0020ef42. After that the original input registers are overwritten and they should revert to being labeled as r4, r5.

[simeonpilgrim]

The behavior in your example IMO is acceptable up to 0020ef42. After that the original input registers are overwritten and they should revert to being labeled as r4, r5.

agreed. thus why I posted this, but understanding how to fix it, I have not mastered.. so I cannot push it forward.

[fenugrec]

Can we still reopen this ? It applies not only to FR but also SuperH and possibly other archs.

[simeonpilgrim]

well I guess I need to test in the latest build, and if it still happens I will reopen.