lld silently creates an non-working executable if both .ctors and .init_array exist

[rui314]

If input object files contain both .ctors and .init_array, the result would contain both .ctors and .init_array, and the result is very likely to crash because some initializer are not executed. We may want to emit a warning from lld if the output may not work due to this issue.

[christopherbate]

I very recently observed this when using ld.lld to replace bfd in a project. It was a huge headache to debug, as I had no idea what was causing random segfaults at runtime with the resulting executables.

I'm wondering what would be the effort to implement the same functionality that bfd/gold have with regards to converting .ctors to .init_array if they both exist.

[christopherbate]

Actually I see that the work was done, but just not merged. https://reviews.llvm.org/D35509

Development was tracked here: #30572

At the end of the thread, the author states:

CUDA 11 has finally switched from .ctors to .init_array! Yet in order to support older CUDAs for a while I've ported my patch to LLD 11 (and fixed the sorting order of sections — the previous patch has sorted .ctors.64534 as .init_array.64534 rather than as .init_array.1001). (I do not propose to merge this patch into LLD due to the lack of interested users.).

Which is ironic because I just inspected CUDA 12.2 and 12.3 linux binaries and they include .ctor sections in several static libs.

[MaskRay]

Duplicate of #30572 and there is nothing changed. I understand the frustration but as of 2023 this appears a CUDA specific issue. You can run objcopy --rename-section .ctors=.init_array --rename-section .dtors=.fini_array $file (https://maskray.me/blog/2021-11-07-init-ctors-init-array) or use OVERWRITE_SECTIONS to place .ctors into .init_array.