ELF-based platforms currently support defining multiple static initializer table sections with differing priorities, for example .init_array.0 or .init_array.100; the default .init_array corresponds to a priority of 65535. When building a shared library or executable, the system linker normally sorts these sections and combines them into a single .init_array section. This change adds the capability to recognize ELF static initializers with priorities other than the default, and to properly sort them by priority, to Orc and the Orc runtime.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/ExecutionEngine/Orc/ELFNixPlatform.cpp | ||
---|---|---|
814 |
compiler-rt/lib/orc/elfnix_platform.cpp | ||
---|---|---|
391 | Does ELF make any guarantees about order-of-initialization beyond priority ordering? We don't currently number MaterializationUnits, so initialization order is already at the mercy of the dependence graph (likely opaque to clients), and the scheduler (if concurrent compilation is enabled). I'm not opposed to stable_sort (I like that it should make run-to-run behavior of llvm-jitlink more stable), but it's probably worth a comment that order of initialization is still not guaranteed in general. |
compiler-rt/lib/orc/elfnix_platform.cpp | ||
---|---|---|
391 | For determinism (using different standard library implementations should give the same result), stable_sort should be used. Relying on the order is user code issue, but that's unrelated to the general determinism guarantee provided by the toolchain (https://maskray.me/blog/2021-11-07-init-ctors-init-array) |
compiler-rt/lib/orc/elfnix_platform.cpp | ||
---|---|---|
379 | I saw that, but it wasn't clear what advantage that would have (as opposed to reversing the mapping in llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp:1060) | |
391 | At the point where this occurs, ELFNixPlatform has already collected all initializers of each priority level into a single entry, so this sort by priority level is already going to be completely deterministic. I can change this to stable_sort but it will never have any effect on the result. |
compiler-rt/lib/orc/elfnix_platform.cpp | ||
---|---|---|
391 | I'd prefer to stick with std::sort. stable_sort seems like it's promising something it wouldn't actually deliver here. |
65536 is better.
See lld/ELF/OutputSections.cpp::576