And then, some calls just don't return

A small number of library procedures are "called" but never actually return. Eventually I'd like to have a way to specify these procedures with anotations in the signature files, but for the moment they are hard coded in the frontend. That's acceptable for the moment as there is only five: _exit, exit, ExitProcess, abort and _assert. Thing is, what happens when you have a branch over one of these calls, as you often do. Typically you end up with phi statements that refer to the call or the statements before it because there's no way to show that these definitions are killed by the call but not defined by it. We could add this to the SSA form but a simpler solution is available. Whenever the decompiler determines that the destination of a call is one of these no return procedures then we simply drop the out edge of the containing basic block. Without an out edge the definitions cannot flow beyond the call.

Using dataflow based type analysis and some of my new changes the decompilation of extract_kyra.exe is currently looking a bit better. In particular, proc9, proc10 and proc2 are showing significant improvement.

Comments

  1. Hmm. That's interesting Tamlin. The exit block for _assert in MSVCRT.DLL is at 0x77C33D8C. There are only two in-edges to this block, 0x77C33D8B which is an int 3 instruction and 0x77C33D95 which is a jump. Although you can step over an int 3 I think it's fair to say that in normal execution we're not going to return from _assert if we followed that path. 0x77C33D95 however is a block with only one in-edge, 0x77C33D90 which also has only one in-edge, 0x77C33D86 which also has only one in-edge, which is the result of a call to the code that displays the "Press Retry to debug the application" dialog. For a console application it's a totally different library too.

    ReplyDelete

Post a Comment

Popular posts from this blog

Disabling OS-X Device Removal Warnings In Yosemite

Rebirth Of The Spaceship

Mars Direct Without Super Heavy Lift