[llvm] [AMDGPU] Call the `FINI_ARRAY` destructors in the correct order (PR #71815)
Joseph Huber via llvm-commits
llvm-commits at lists.llvm.org
Thu Nov 9 13:41:05 PST 2023
jhuber6 wrote:
> This needs tests with multiple translation units. Multiple IR files with appending linkage would also be fine. It also needs tests that _don't_ force the ordering with priority.
>
> Destructors need to fire in reverse order of constructors. If your comment is accurate to the implementation:
>
The tests here are only concerned with the backend. For lowering of these to the `init_array` and `.fini_array` sections we have tests in `lld`. For direct use on the GPU we have `libc` and the tests added in https://github.com/llvm/llvm-project/pull/71739 which requires this patch to pass.
> > The destructors stored in FINI_ARRAY are actually stored in reverse order
>
> Then that won't happen for all of the above test cases.
The commit message was not clear enough. The `.init_array` and `.fini_array` sections are created by the linker. The section is sorted according to its priority. If two destructors have identical priority, the order they execute in is somewhat arbitrary, but more or less just boils down to the order they were appended in the linker (e.g. if foo.c came before bar.c in the linker). This is separate from the destructor handling in the C++ language which uses `__cxa_atexit` to ensure that paired constructors have destructors execute in a fixed order once initialized.
The execution of this should be identical to the handling you would find in `glibc`, `musl`, or any other implementation that uses the init / fini arrays. The main difference here is that we emit a kernel to do this traversal while those implementations have a function for this that the startup code calls. This implementation is correct and in-line with standard semantics as far as I'm aware.
https://github.com/llvm/llvm-project/pull/71815
More information about the llvm-commits
mailing list