0

Well, I've got an function that the pseudo code looks like:

void d4l_auxadc_cali_unlocked_ioctl()
{
  unsigned int v0; // r1@1
  unsigned int v1; // r7@1
  ...

However, I am aware that the definition of the function is as follow:

int d4l_auxadc_cali_unlocked_ioctl(void* a1, unsigned long a2, unsigned long a3)

So I tell the decompiler what I know by using the "Set Item Type", and here is what I got:

int __fastcall d4l_auxadc_cali_unlocked_ioctl(void *a1, unsigned __int32 a2, unsigned __int32 a3)
{
  unsigned int v3; // r1@1
  unsigned int v4; // r7@1

The problem is, the local variable "v3" is actually as same as the function argument "a2", but the decompiler failed to connect them together.

I've tried to map "v3" to "a2" by using "Map to another variable", but I am only allow to do the mapping with "v4", "v5" ...

What can I do now ... ?

And BTW, does anyone know the meaning of "@1" as a part of "r1@1" ?

The head of assembly codes is as follow. It seems that none of them modify the r1 register, so I don't know why the compile chooses to create a different variable.

ROM:C04C54E8                 MOV             R12, SP
ROM:C04C54EC                 STMFD           SP!, {R4-R7,R11,R12,LR,PC}
ROM:C04C54F0                 SUB             R11, R12, #4
ROM:C04C54F4                 STR             LR, [SP,#0x1C+var_20]!
ROM:C04C54F8 ; 25:   d4l___gnu_mcount_nc();
ROM:C04C54F8                 BL              d4l___gnu_mcount_nc
ROM:C04C54FC ; 28:   d4l_mutex_lock(&unk_C0D661A4);
ROM:C04C54FC                 LDR             R0, =unk_C0D661A4 ; void *
                             //So far, none of the codes have modified r1, so why the compiler chooses to create a v3 ?
ROM:C04C5500 ; 26:   v4 = v3;
ROM:C04C5500                 MOV             R7, R1
ROM:C04C5504 ; 27:   v6 = v5;
ROM:C04C5504                 MOV             R4, R2
ROM:C04C5508                 BL              d4l_mutex_lock
                             //Note that d4l_mutex_lock only takes one argument.
ROM:C04C550C ; 29:   if ( v4 == 1074031362 )
ROM:C04C550C                 LDR             R3, =0x40046B02
ROM:C04C5510                 LDR             R6, =unk_C0D661A4
ROM:C04C5514                 CMP             R7, R3
ROM:C04C5518                 LDR             R5, =0xC0E748B4
ROM:C04C551C                 BEQ             loc_C04C55EC
0

The @1 part should be the instruction number within the assembly where the variable is defined.

For the rest of your question, you'll probably have to look at the assembly code. r1 is the register to pass the second argument on an ARM processor all right, but a function call doesn't have to preserve its arguments, so the compiler is allowed to use r1 for something else once it doesn't need the argument (a2) anymore. I'd assume the assembly modifies r1 somewhere, which makes it different from a2, so the decompiler chooses to create a different variable name for it instead of producing a (possibly confusing) assignment to a2.

If your function calls other functions, it will even need to overwrite r0..r3 (depending on the number of arguments to that function), so most code i've seen saves the arguments to the stack, or some other register. If your r1 doesn't get saved anywhere (because it's just needed at the start of your function and never again), this might be the reason why the decompiler doesn't want to assign a variable name, as well.

To get a definite answer, i think you'd have to ask your question on the hex-rays forum and include the disassembled code, they tend to have excellent support there.

| improve this answer | |
  • Thanks for reply. However, according to the assembly codes, I am still confused about why the compile chooses to create a different variable. I've post the assembly codes on the question, pls take a look and any help is appreciate. – dr4lamb Mar 8 '15 at 7:16
  • 1
    The call to d4l__gnu_mount_nc isn't required to preserve registers r0-r3, so for all ida knows, r1 is undefined after that call. If you know that function doesn't modify r1, you can use the _spoils keyword. See hex-rays.com/products/ida/support/idadoc/1361.shtml. – Guntram Blohm supports Monica Mar 8 '15 at 12:59
  • Great help! It solved my problem. Thanks a log. – dr4lamb Mar 9 '15 at 2:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.