Milestone 4.5: Stack Frame Recovery #16
Conversation
…ysis Argument recovery is now aware of register aliasing (eax, rax, ...) and recovers argument types and names accordingly. Return type is recovered from the last user of a return value register specified by a calling convention, in a basic block with a `llvm::ReturnInst`. If it's an `llvm::StoreInst` (aka a write) we take the type and use it as the function return type. If no such write is found, the function returns `void`. If more than one return type candidate is found, we terminate. This should be enhanced in the future.
Since we don't actually use the pass anymore
…eeds further testing.
| @@ -405,7 +405,7 @@ bool ParameterRegistry::doInitialization(Module& m) | |||
|
|
|||
| bool ParameterRegistry::runOnModule(Module& m) | |||
| { | |||
| aaHack.reset(new ProgramMemoryAAResult); | |||
| aaHack.reset(new fcd::AddressSpaceAAResult); | |||
There was a problem hiding this comment.
Please indent using 2 spaces, not tabs.
There was a problem hiding this comment.
This is an original fcd source that didn't see any change besides this one, so I thought it would be better not to reformat it or make any big changes. Should I reformat it completely?
There was a problem hiding this comment.
Hrm in that case leave it for now. Same for below.
| @@ -11,7 +11,7 @@ | |||
| #define fcd__callconv_params_registry_h | |||
|
|
|||
| #include "targetinfo.h" | |||
There was a problem hiding this comment.
Please adjust all includes to be relative to the root of the source tree, so I assume in this case: #include "fcd/callconv/targetinfo.h".
There was a problem hiding this comment.
Same as above. Actually I don't know why this even shows up as a change. Maybe because it was changed at one point and then reverted?
fcd/main.cpp
Outdated
| @@ -80,6 +80,8 @@ DEFINE_string(frameworks, "", | |||
| "Apple framework dirs to be used for declarations"); | |||
| DEFINE_string(includes, "", "Directories to search headers in"); | |||
|
|
|||
| DECLARE_string(callconv); | |||
There was a problem hiding this comment.
Maybe make this calling_convention, or maybe default_calling_convention. I like command-line arguments to be, as much as possible, self-describing, kind of like variable names.
There was a problem hiding this comment.
And lol about me using arch and os.. which are terse. Humans are inconsistent!
There was a problem hiding this comment.
This is actually another leftover from my experiments with the original fcd code. Deleted in
7effdc6. But comment noted for future.
| @@ -457,33 +457,33 @@ class Main { | |||
| // Default passes | |||
| vector<string> passNames = { | |||
There was a problem hiding this comment.
I know I sound like a broken record at this point. But the main.cpp refactor is coming! Issue #4 for more.
fcd/pass_argrec_remill.cpp
Outdated
| return true; | ||
| } | ||
|
|
||
| llvm::ModulePass *createRemillArgumentRecoveryPass() { |
There was a problem hiding this comment.
Make empty parameter lists take void.
There was a problem hiding this comment.
Addressed in 01a78f6
| void RemillArgumentRecovery::getAnalysisUsage( | ||
| llvm::AnalysisUsage &usage) const {} | ||
|
|
||
| bool RemillArgumentRecovery::runOnModule(llvm::Module &module) { |
There was a problem hiding this comment.
Can you add a bit more commenting in this file to describe the gist of what's going on?
There was a problem hiding this comment.
Addressed in 01a78f6. Also added comments to RemillStackRecovery to clarify the steps of the algorithm.
This PR replaces the original stack frame recovery pass with a simpler one, tailored to remill-lifted IR. The pass attempts to recover local variables of functions and parameters passed into the function via stack.
This PR requires PR #13
The algorithm first attempts to find stack objects (local variables and stack parameters) based on the usage of pointers derived from the stack pointer register argument of functions (which was recovered previously via the register argument recovery pass). These pointers are then promoted to
allocainstructions, which in the case of local variables is the final transformation.The next phase of recovery deals with stack parameters. The algorithm analyzes a range of instructions between two calls to lifted (and argument recovered) functions and looks for
storeinstructions to stack objects (allocacreated values) that correspond to writes of stack parameters. The whole range is constrained to be in a single basic block. After all calls are processed a canonical call is decided upon (at the moment the call with least parameters) and the called function prototype is derived from it.If the function has no call to it, stack parameters are inferred from stack objects used in the body of the function.
Finally parameters are loaded into calls and stored into stack objects (
allocainsts) in the called functions.