interpetBCO doesn't get stripped from executables
Looking at the symbols linked into a simple Hello world program (e.g. with nm -S --size-sort hello_world
), interpretBCO from the RTS is one of the larger functions. Unless I'm missing something, a compiled program shouldn't need the bytecode interpreter.
The reason it gets linked and not dead-code stripped is that the scheduler has a hardcoded reference to it in case ThreadInterpret:
, and figuring out if that particular what_next value is possible is out of reach of the linker.
I'm thinking the ThreadInterpret state could be removed, and replaced with a more generic "resume by calling C function" state, with a function pointer on the stack. Paths that enter this state would push a function pointer to interpretBCO, and so the linker will link against interpretBCO iff it's actually used.
Or perhaps it would be possible to have the interpreter entry point follow STG calling conventions and use ThreadRunGHC?
Trac metadata
Trac field | Value |
---|---|
Version | 8.0.1 |
Type | Task |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Runtime System |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | simonmar |
Operating system | |
Architecture |