Re: convert x86 assembly to c ?

vbdis@aol.com (VBDis)
28 Sep 2000 22:16:05 -0400

          From comp.compilers

Related articles
convert x86 assembly to c ? winsim@winsim.com (Lynn McGuire) (2000-09-24)
Re: convert x86 assembly to c ? s337240@student.uq.edu.au (Trent Waddington) (2000-09-25)
Re: convert x86 assembly to c ? Martin.Ward@durham.ac.uk (2000-09-25)
Re: convert x86 assembly to c ? dlindauer@notifier-is.net (david lindauer) (2000-09-25)
Re: convert x86 assembly to c ? winsim@winsim.com (Lynn McGuire) (2000-09-25)
Re: convert x86 assembly to c ? winsim@winsim.com (Lynn McGuire) (2000-09-28)
Re: convert x86 assembly to c ? vbdis@aol.com (2000-09-28)
Re: convert x86 assembly to c ? bsheff2@yahoo.com (2000-10-01)
| List of all articles for this month |

From: vbdis@aol.com (VBDis)
Newsgroups: comp.compilers
Date: 28 Sep 2000 22:16:05 -0400
Organization: AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com
References: 00-09-180
Keywords: decompile

Trent Waddington <s337240@student.uq.edu.au> schreibt:


>A big problem with decompilation in general is
>determining the number of parameters that a procedure takes. Liveness
>analysis can do this, but on x86 this means you have to determine what
>stack locations are used before they are defined. With traditional C
>calling convention this is not a problem (ie, unix is ok) but when you
>introduce pascal calling conventions - callee pop - you have no way of
>knowing exactly how the stack pointer is changed after each call.


Perhaps you should revise your model?


Subroutine calls in general can result in any change to the stack;
some subroutines will never return, others take arguments from the
code segment, following the call, and will return to some other
location. That's a situation you must live with.


I'd distinguish regular from exceptional subroutines. Regular
subroutines have a fixed amount of argument bytes on the stack, which
are popped by either the caller or the callee. Exceptional
subroutines can do to the stack whatever they like, and can (not)
return to any arbitrary code location.


All according indications can be found in the code of any subroutine,
with a simple analysis of sequential instructions.


DoDi


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.