Allocate global variables before populating constants #2623
Conversation
|
Fixes #2622 |
|
This probably needs more design before being considered for merging |
glguy
force-pushed
the
consts-depend-on-globals
branch
from
b6cbeff to
9d6b21a
Compare
| (pureVal enable_alloc_all_globals) | ||
| Experimental | ||
| [ "Enable allocation of all globals automatically. This is necessary when" | ||
| , " constants depend on the addresses of globals." |
There was a problem hiding this comment.
Can you add something here about it affecting the behavior of llvm_load_module and mir_load_module? (Does it affect the Java end of things? AFAICR things work somewhat differently there.)
Also it's probably a good idea to mention what this means in terms of llvm_alloc_global, and maybe also say that this is likely a temporary workaround, and point at the issue.
There was a problem hiding this comment.
This shouldn't affect the behavior of the JVM or MIR backends at all. Besides the fact that this PR doesn't touch any code in those two backends, it is also worth nothing that both backends handle globals differently enough from the LLVM backend that it's not really meaningful to talk about how enable_alloc_all_globals would interact with them.
There was a problem hiding this comment.
I apparently thought it was updating shared code. N/M
|
(The build failures are because you need to initialize the new thing in the remote API's dummy copy of the interpreter state.) |
| (pureVal enable_alloc_all_globals) | ||
| Experimental | ||
| [ "Enable allocation of all globals automatically. This is necessary when" | ||
| , " constants depend on the addresses of globals." |
There was a problem hiding this comment.
This shouldn't affect the behavior of the JVM or MIR backends at all. Besides the fact that this PR doesn't touch any code in those two backends, it is also worth nothing that both backends handle globals differently enough from the LLVM backend that it's not really meaningful to talk about how enable_alloc_all_globals would interact with them.
This is necessary when global constants depend on the addresses of global variables.
When using no automatic allocations, constant globals must be manually allocated just the same as mutable globals.
```
let llvm_use_constant name = do {
llvm_alloc_global name;
llvm_points_to (llvm_global name)
(llvm_global_initializer name);
};
```
glguy
force-pushed
the
consts-depend-on-globals
branch
from
9d6b21a to
083a004
Compare
| =<< Crucible.initializeMemoryConstGlobals bak ctx llvm_mod | ||
| LLVMAllocAllGlobals -> | ||
| Crucible.populateConstGlobals bak (view Crucible.globalInitMap mtrans) | ||
| =<< Crucible.initializeAllMemory bak ctx llvm_mod |
There was a problem hiding this comment.
There's a populateAllGlobals on the Crucible side and I would hazard a guess you probably want it here...
There was a problem hiding this comment.
I was assuming that would set the mutable globals to their initial values, which is a stronger precondition than I want.
Constants can depend on the addresses of global variables