[PATCH] D127056: [ORC][ORC_RT] Handle ELF .init_array with non-default priority
Fangrui Song via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Jun 6 17:03:01 PDT 2022
MaskRay added inline comments.
================
Comment at: compiler-rt/lib/orc/elfnix_platform.cpp:391
+ using SectionList = std::vector<ExecutorAddrRange>;
+ std::sort(MOJDIs.InitSections.begin(), MOJDIs.InitSections.end(),
+ [](const std::pair<std::string, SectionList> &LHS,
----------------
lhames wrote:
> MaskRay wrote:
> > stable_sort
> Does ELF make any guarantees about order-of-initialization beyond priority ordering?
>
> We don't currently number `MaterializationUnit`s, 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.
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)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D127056/new/
https://reviews.llvm.org/D127056
More information about the llvm-commits
mailing list