Prev: Using IDA Pro v4.3
Next: COM assembly program
From: emmerik on 4 Aug 2006 20:24
> Fourth, one of the problems with decompilation to C is that C implements
> stronger type checking than assembly. A simple example is that an Intel
> register can be used as a address (i.e., pointer), 32-bit value, 16-bit
> value, 8-bit value, without creating any problems. When decompiled to C,
> each register ends up being a union of a bunch of types, which defeats the
> purpose of type checking of C.

Yes, type analysis is an important part of decompilation, and we
address this issue.

Essentially, when a live range of a register has a different type to
another live range, it is emitted as a different local variable, and
that variable is declared with the appropriate type. When more than one
type us used in one live range, casts are emitted. The finer points of
all this are being worked on right now. At present, Boomerang creates
union types, but these should not be present in the decompiled output
unless the user forces it, I believe.

> It also creates many different names,
> depending on the type, for a single register.

Well that's how the problem is solved. It depends if you really wanted
to know that that variable which represents the number of widgets sold
last month was stored in register ecx in the original program. We
actually emit variables with names like ecx, but also others like
local13 with a comment of r25 (which is an internal representation for
ecx, it should put the name ecx in there I guess).

- emmerik

 | 
Pages: 1
Prev: Using IDA Pro v4.3
Next: COM assembly program