Implement --ctors-in-init-array.

[MaskRay]

Summary

This patch defines InitFiniSection synthetic section to convert
.[cd]tors to .{init,fini}_array.

Unlike https://reviews.llvm.org/D35509, this patch also adds
--no-ctors-in-init-array option so that you can choose to not merge
.[cd]tors into .{init,fini}_array.

[grimar]

lld/ELF/OutputSections.cpp

331

Should these two just be inlined instead?

lld/ELF/SyntheticSections.cpp

92

I would write "while .init_array.65535 is the lowest"

103

unsigned?

104

I think we need to check what to_integer returns.

112

Since you do not pass anything else than

".ctors" / ".ctors." / ".dtors" / ".dtors."

(from createInitFiniSections)

The code could probably be something like:

static StringRef toInitFiniName(StringRef S, uint32_t Type) {
  StringRef Prefix = (Type == SHT_INIT_ARRAY) ? ".init_array." : ".fini_array.";
  if (S.back() != '.')
    return Saver.save(Prefix + "65537");

  unsigned N = 0;
  if (to_integer(S.substr(7), N, 10))
    error("eeerrr");
  return Saver.save(Prefix + Twine(65535 - N));
}

128

runtime

lld/ELF/Writer.cpp

403

I would probably use

for (InputSectionBase *&Base : InputSections)

because the presence of I makes me search around where it is used as an index.

[grimar]

lld/ELF/SyntheticSections.cpp

92

My rewording was not entirely correct. Probably it could be the following:

.ctors.0 is the lowest priority while .init_array.0 is the highest.

[ruiu]

lld/ELF/OutputSections.cpp

331

No I don't think so.

lld/ELF/SyntheticSections.cpp

92

I don't think that's a better comment because it doesn't say anything about what is the highest value. Is that 100, 255 or some other value?

103

In general, you shouldn't use unsigned if the only reason to do that is a number cannot be negative, but in this particular case, I think uint16_t is the best choice.

112

You should avoid extra allocation, but I changed the code along with that direction.

lld/ELF/Writer.cpp

403

I disagree. A reference to a pointer to something is harder to understand than an just integer.

[ruiu]

• address review comments

[• espindola]

I like the general idea. These days it is hopefully uncommon to encounter .ctor/.dtor sections so having something simple is better.

lld/ELF/OutputSections.h

124

Why in OutputSections.h?

lld/ELF/SyntheticSections.cpp

98

Could this use ".init_array"? Should elf::getPriority return 65537 for ".init_array"?

119

using make<std::vector> looks somewhat odd. Either allocate a plain buffer or add a comment that we intentionally "leak" this std::vector.

lld/ELF/Writer.cpp

402

Could this logic be in InputFile so that we don't even create an InputSection for the .ctor/.dtor sections?

403

For what it is worth I also prefer the *& version.

[grimar]

lld/ELF/SyntheticSections.cpp

92

But your version also does not say what is the lowest value for .init_array.*, for example.
Can it be something like the following then?

// Section names may include priorities, e.g. .ctors.N or .init_array.N.
// For ".ctors.N" N is a value in [0..65535], where 0 means lowest priotity and 65535 is the highest.
// For ".init_array.N" ....

112

I do not think it was worth to avoid the allocation here. .ctors and .dtors are probably too rare
to care about that.

Anyways you allocate additional vector right below, what seems to be much more sensitive :)
(btw one of the way would be to create a synthetic section for that and it would just write
initial data in a reversed order without allocating the additional buffers. But again, I do not think
it would worth to do for these sections).

Your version is OK for me.

[ruiu]

I found that this patch isn't correct. Sorry guys. The issue is that we need to reverse the contents after applying relocations. This patch reverses it before applying relocations. I need to fix that. I'll update the patch.

[ChuanqiXu]

In D45508#1066336, @ruiu wrote:

I found that this patch isn't correct. Sorry guys. The issue is that we need to reverse the contents after applying relocations. This patch reverses it before applying relocations. I need to fix that. I'll update the patch.

Hi, may I ask about the detail for the new patch. I just met the problems that sections in .ctors need to be added to .init_array.

[ChuanqiXu]

I rebased this patch, did some simple change to make it work at trunk and reverse the contents of .ctors after applying relocations as @ruiu mentioned in comments. May I ask is it ok for me to create a new diffusion? I am not familiar with the rule for the situation in the LLVM community convention. @MaskRay @grimar

[haampie]

Would be nice to have this (enabled by default, like in binutils ld), since due to an oversight, GCC 12 is the first GCC to actually enable .init_array for cross-compilers targeting Linux. [1]

That leads to annoying issues where building clang with such a GCC < 12 produces a libclang_rt.profile.a with .ctors, so that clang -fprofile-generate -fuse-ld=lld simply does not work: it ends up mixing .ctors from the runtime library and .init_array from the application, glibc doesn't execute the .ctors bits, but those contain the constructor of a global that initializes profiling. [2]

This is not an issue with ld, since it generates ELF files with just .init_array by default. So clang -fprofile-generate -fuse-ld=ld works just fine.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100896
[2] https://github.com/JuliaLang/julia/pull/45641

[MaskRay]

In D45508#3585086, @haampie wrote:

Would be nice to have this (enabled by default, like in binutils ld), since due to an oversight, GCC 12 is the first GCC to actually enable .init_array for cross-compilers targeting Linux. [1]

That leads to annoying issues where building clang with such a GCC < 12 produces a libclang_rt.profile.a with .ctors, so that clang -fprofile-generate -fuse-ld=lld simply does not work: it ends up mixing .ctors from the runtime library and .init_array from the application, glibc doesn't execute the .ctors bits, but those contain the constructor of a global that initializes profiling. [2]

This is not an issue with ld, since it generates ELF files with just .init_array by default. So clang -fprofile-generate -fuse-ld=ld works just fine.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100896
[2] https://github.com/JuliaLang/julia/pull/45641

This patch may be more relevant few years ago but at this point, it mostly just adds come complexity which will need to be cleaned up soon.

One can run objcopy --rename-section .ctors=.init_array --rename-section .dtors=.fini_array a.o to fix object files using .ctors/.dtors.

Note that the upstream GCC configuration deviates considerably with what some distros use in practice.
Many specify --enable-initfini-array explicitly.
(Deviate this topic a bit: if you'd like to help, there is a default-pie thing https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103398)

glibc doesn't execute the .ctors bits.

This is not so accurate. See https://maskray.me/blog/2021-11-07-init-ctors-init-array#ctors-and-.dtors

[haampie]

@MaskRay, not sure if I follow

This is not so accurate.

Do you mean it's gcc not libc? In any case, when using lld, constructors in object files compiled with default cross GCC < 12 configuration are not run:

$ cat foo.cc 
#include <iostream>
class Foo {
public:
    Foo() { std::cout << "foo\n"; }
};
Foo foo;

$ cat main.cc 
#include <iostream>
int main() {
    std::cout << "hello\n";
}

$ gcc --version
x86_64-linux-gnu-gcc (GCC) 8.1.0

$ gcc -c foo.cc
$ clang++ main.cc foo.o 
$ ./a.out 
foo
hello

$ clang++ -fuse-ld=lld main.cc foo.o 
$ ./a.out 
hello

Is that expected or not?

Edit: ah, I think I get it. GCC provides ctrbegin.o and crtend.o with the sentinel values, but if GCC is compiled with --enable-initfini-array, those are omitted. So you simply can't use object files with ctors if your GCC is compiled with --enable-initfini-array. And in the example above, the initial GCC was compiled without --enable-initfini-array, and the clang later uses a different system GCC under the hood which was compiled with --enable-initfini-array.

In any case, it would be much more convenient if lld had the same behavior as ld, cause this is a pain to debug.

[MaskRay]

In D45508#3588228, @haampie wrote:

@MaskRay, not sure if I follow

This is not so accurate.

Do you mean it's gcc not libc? In any case, when using lld, constructors in object files compiled with default cross GCC < 12 configuration are not run:

$ cat foo.cc 
#include <iostream>
class Foo {
public:
    Foo() { std::cout << "foo\n"; }
};
Foo foo;

$ cat main.cc 
#include <iostream>
int main() {
    std::cout << "hello\n";
}

$ gcc --version
x86_64-linux-gnu-gcc (GCC) 8.1.0

$ gcc -c foo.cc
$ clang++ main.cc foo.o 
$ ./a.out 
foo
hello

$ clang++ -fuse-ld=lld main.cc foo.o 
$ ./a.out 
hello

Is that expected or not?

Edit: ah, I think I get it. GCC provides ctrbegin.o and crtend.o with the sentinel values, but if GCC is compiled with --enable-initfini-array, those are omitted. So you simply can't use object files with ctors if your GCC is compiled with --enable-initfini-array. And in the example above, the initial GCC was compiled without --enable-initfini-array, and the clang later uses a different system GCC under the hood which was compiled with --enable-initfini-array.

In any case, it would be much more convenient if lld had the same behavior as ld, cause this is a pain to debug.

Expected. And your analysis is about right. It would be convenient few years ago, but the value is significantly low nowadays, now with the GCC configure.ac fixed.

Note: even several years ago, the GCC default configure.ac behavior may not be a strong enough motivation. That is mainly a "GCC default has diverged a lot from the practice" issue.
I agree that we want to make system GCC usable with lld, but that doesn't mean a random manual build of GCC forgetting --enable-initfini-array.

[skirkovski]

Hey folks,

Is this patch still relevant to the upstream community ?

GCC12 is starting to be deployed more and more in production and this kind of issues are at scale for all kinds of companies, so there is interest to get this landed or to find a workaround that does not include rebuilding everything.

LD' s inker script has for years put all .{c,d]tors in .{init,fini}_array. Do you see any issue in implementing the same for lld ?

[MaskRay]

In D45508#4135578, @skirkovski wrote:

Hey folks,

Is this patch still relevant to the upstream community ?

No, it is increasingly unnecessary, see https://maskray.me/blog/2021-11-07-init-ctors-init-array , especially the chapter ".ctors to .init_array transition".

GCC12 is starting to be deployed more and more in production and this kind of issues are at scale for all kinds of companies, so there is interest to get this landed or to find a workaround that does not include rebuilding everything.

LD' s inker script has for years put all .{c,d]tors in .{init,fini}_array. Do you see any issue in implementing the same for lld ?

I think you misunderstand things. GCC 4.7 switched from .ctors to .init_array . At the current GCC 12 time .ctors is very obsoleted now.

[skirkovski]

I think you misunderstand things. GCC 4.7 switched from .ctors to .init_array . At the current GCC 12 time .ctors is very obsoleted now.

I don't think I am. I was debugging this issue today. I had some binaries and libraries built and linked with gcc9, now while transitioning to gcc12 I can clearly see that that .ctors from those libraries are present but are not executed when the resulting binary is linked with lld, only .init_array.

But sure whatever, I really didn't expect anything else with (atleast) 3 attempts to fix this upstream.

[MaskRay]

In D45508#4136044, @skirkovski wrote:

I think you misunderstand things. GCC 4.7 switched from .ctors to .init_array . At the current GCC 12 time .ctors is very obsoleted now.

I don't think I am. I was debugging this issue today. I had some binaries and libraries built and linked with gcc9, now while transitioning to gcc12 I can clearly see that that .ctors from those libraries are present but are not executed when the resulting binary is linked with lld, only .init_array.

But sure whatever, I really didn't expect anything else with (atleast) 3 attempts to fix this upstream.

You might build a GCC by yourself, instead of using a distro-provided one. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100896

If you want GCC's .ctors work without .ctors=>.init_array conversion, you can patch GCC libgcc/crtstuff.c to always support .ctors.
Alternatively, search objcopy on https://maskray.me/blog/2021-11-07-init-ctors-init-array (just updated).

lld/ELF/Config.h

struct Configuration {
   bool ARMHasMovtMovw = false;
   bool ARMJ1J2BranchEncoding = false;
   bool AsNeeded = false;
   bool Bsymbolic;
   bool BsymbolicFunctions;
   bool CheckSections;
   bool CompressDebugSections;
   bool Cref;
+  bool CtorsInInitArray;
   bool DefineCommon;
   bool Demangle = true;
   bool DisableVerify;
   bool EhFrameHdr;
   bool EmitRelocs;
   bool EnableNewDtags;
   bool ExportDynamic;
   bool FixCortexA53Errata843419;

lld/ELF/Driver.cpp

void LinkerDriver::readConfigs(opt::InputArgList &Args) {
   Config->AuxiliaryList = args::getStrings(Args, OPT_auxiliary);
   Config->Bsymbolic = Args.hasArg(OPT_Bsymbolic);
   Config->BsymbolicFunctions = Args.hasArg(OPT_Bsymbolic_functions);
   Config->CheckSections =
       Args.hasFlag(OPT_check_sections, OPT_no_check_sections, true);
   Config->Chroot = Args.getLastArgValue(OPT_chroot);
   Config->CompressDebugSections = getCompressDebugSections(Args);
   Config->Cref = Args.hasFlag(OPT_cref, OPT_no_cref, false);
+  Config->CtorsInInitArray =
+      Args.hasFlag(OPT_ctors_in_init_array, OPT_no_ctors_in_init_array, true);
   Config->DefineCommon = Args.hasFlag(OPT_define_common, OPT_no_define_common,
                                       !Args.hasArg(OPT_relocatable));
   Config->Demangle = Args.hasFlag(OPT_demangle, OPT_no_demangle, true);
   Config->DisableVerify = Args.hasArg(OPT_disable_verify);
   Config->Discard = getDiscard(Args);
   Config->DynamicLinker = getDynamicLinker(Args);
   Config->EhFrameHdr =
       Args.hasFlag(OPT_eh_frame_hdr, OPT_no_eh_frame_hdr, false);

lld/ELF/Options.td

 
 def color_diagnostics_eq: J<"color-diagnostics=">,
   HelpText<"Use colors in diagnostics">;
 
 defm cref: B<"cref",
     "Output cross reference table",
     "Do not output cross reference table">;
 
+defm ctors_in_init_array: B<"ctors-in-init-array",
+    "Merge .ctors/.dtors with .init_array/.fini_array",
+    "Do not merge .ctors/.dtors with .init_array/.fini_array">;
+
 defm define_common: B<"define-common",
     "Assign space to common symbols",
     "Do not assign space to common symbols">;
 
 defm demangle: B<"demangle",
     "Demangle symbol names",
     "Do not demangle symbol names">;
 

 // Options listed below are silently ignored for now for compatibility.
 def allow_shlib_undefined: F<"allow-shlib-undefined">;
 def detect_odr_violations: F<"detect-odr-violations">;
 def g: Flag<["-"], "g">;
 def long_plt: F<"long-plt">;
 def no_add_needed: F<"no-add-needed">;
 def no_allow_shlib_undefined: F<"no-allow-shlib-undefined">;
 def no_copy_dt_needed_entries: F<"no-copy-dt-needed-entries">;
-def no_ctors_in_init_array: F<"no-ctors-in-init-array">;
 def no_keep_memory: F<"no-keep-memory">;
 def no_mmap_output_file: F<"no-mmap-output-file">;
 def no_warn_mismatch: F<"no-warn-mismatch">;
 defm rpath_link: Eq<"rpath-link">;
 def sort_common: F<"sort-common">;
 def stats: F<"stats">;
 def warn_execstack: F<"warn-execstack">;
 def warn_once: F<"warn-once">;
 def warn_shared_textrel: F<"warn-shared-textrel">;
 def EB : F<"EB">;
 def EL : F<"EL">;
 def G: JoinedOrSeparate<["-"], "G">;
 def Qy : F<"Qy">;

lld/ELF/OutputSections.h

private:
   // Used for implementation of --compress-debug-sections option.
   std::vector<uint8_t> ZDebugHeader;
   llvm::SmallVector<char, 1> CompressedData;
 
   uint32_t getFiller();
 };
 
 int getPriority(StringRef S);
+bool isCrtbegin(StringRef S);
+bool isCrtend(StringRef S);
 
 std::vector<InputSection *> getInputSections(OutputSection* OS);
 
 // All output sections that are handled by the linker specially are
 // globally accessible. Writer initializes them, so don't use them
 // until Writer is initialized.
 struct Out {
   static uint8_t First;

lld/ELF/OutputSections.cpp

static bool isCrtBeginEnd(StringRef S, StringRef Filename) {
   if (!S.endswith(".o"))
     return false;
   S = S.drop_back(2);
   if (S.endswith(Filename))
     return true;
   return !S.empty() && S.drop_back().endswith(Filename);
 }
 
-static bool isCrtbegin(StringRef S) { return isCrtBeginEnd(S, "crtbegin"); }
-static bool isCrtend(StringRef S) { return isCrtBeginEnd(S, "crtend"); }
+bool elf::isCrtbegin(StringRef S) { return isCrtBeginEnd(S, "crtbegin"); }
+bool elf::isCrtend(StringRef S) { return isCrtBeginEnd(S, "crtend"); }
 
 // .ctors and .dtors are sorted by this priority from highest to lowest.
 //
 //  1. The section was contained in crtbegin (crtbegin contains
 //     some sentinel value in its .ctors and .dtors so that the runtime
 //     can find the beginning of the sections.)
 //
 //  2. The section has an optional priority value in the form of ".ctors.N"

lld/ELF/SyntheticSections.h

 
 private:
   std::vector<Thunk *> Thunks;
   size_t Size = 0;
 };
 
 InputSection *createInterpSection();
 MergeInputSection *createCommentSection();
+InputSection *createInitFiniSection(InputSection *Sec);
 void decompressSections();
 void mergeSections();
 
 Defined *addSyntheticLocal(StringRef Name, uint8_t Type, uint64_t Value,
                            uint64_t Size, InputSectionBase &Section);
 
 // Linker generated sections which can be used as inputs.
 struct InX {

lld/ELF/SyntheticSections.cpp

 // With this feature, you can identify LLD-generated binaries easily
 // by "readelf --string-dump .comment <file>".
 // The returned object is a mergeable string section.
 MergeInputSection *elf::createCommentSection() {
   return make<MergeInputSection>(SHF_MERGE | SHF_STRINGS, SHT_PROGBITS, 1,
                                  getVersion(), ".comment");
 }
 
+// Returns an .{init,fini}_array section name for a given .ctors/.dtors
+// section name. For example, it returns ".init_array.10000" for
+// ".ctors.55535".
+//
+// Section names may include priorities, e.g. .ctors.30 or .init_array.101.
+// .ctors.65535 is the highest priority while .init_array.0 is the highest.
+// So we need to translate the number.
+static StringRef toInitFiniName(StringRef S) {
+  // .ctors without any priority should have the lowest priority (i.e. the
+  // greatest number) than any .init_array, so priority 65537 is assigned.
+  if (S == ".ctors")
+    return ".init_array.65537";
+  if (S == ".dtors")
+    return ".fini_array.65537";
+
+  if (S.startswith(".ctors.")) {
+    int N = 0;
+    to_integer(S.substr(7), N, 10);
+    return Saver.save(".init_array." + Twine(65535 - N));
+  }
+
+  if (S.startswith(".dtors.")) {
+    int N = 0;
+    to_integer(S.substr(7), N, 10);
+    return Saver.save(".fini_array." + Twine(65535 - N));
+  }
+
+  llvm_unreachable("unexpected section name");
+}
+
+// Create an .{init,fini}_array section from a given .ctors/.dtors section.
+//
+// Both types of sections are to call constructors or destructors of
+// global objects. .{init,fini}_array are newer, and in most systems,
+// they are used exclusively. However, there are still old object files
+// out there that contain .ctors/.dtors, so we need to handle them by
+// converting them to .init/fini.
+InputSection *elf::createInitFiniSection(InputSection *Sec) {
+  auto *Contents = make<std::vector<uint8_t>>(Sec->Data.size());
+
+  // A .[cd]tors section contains function pointers that are executed at
+  // rutnime from the last one to the first one. .{init,fini}_array also
+  // contains function pointers, but the order the runtime calls them is the
+  // opposite. So, when we convert a .[cd]tors to .{init,fini}_array, we need
+  // to reverse the contents.
+  if (Config->Is64)
+    llvm::copy(llvm::reverse(Sec->getDataAs<uint64_t>()),
+               reinterpret_cast<uint64_t *>(Contents->data()));
+  else
+    llvm::copy(llvm::reverse(Sec->getDataAs<uint32_t>()),
+               reinterpret_cast<uint32_t *>(Contents->data()));
+
+  uint32_t Type =
+      Sec->Name.startswith(".ctors") ? SHT_INIT_ARRAY : SHT_FINI_ARRAY;
+
+  auto *Ret = make<InputSection>(nullptr, SHF_ALLOC, Type, Config->Wordsize,
+                                 *Contents, toInitFiniName(Sec->Name));
+  Ret->Live = true;
+  return Ret;
+}
+
 // .MIPS.abiflags section.
 template <class ELFT>
 MipsAbiFlagsSection<ELFT>::MipsAbiFlagsSection(Elf_Mips_ABIFlags Flags)
     : SyntheticSection(SHF_ALLOC, SHT_MIPS_ABIFLAGS, 8, ".MIPS.abiflags"),
       Flags(Flags) {
   this->Entsize = sizeof(Elf_Mips_ABIFlags);
 }
 

lld/ELF/Writer.cpp

if (InX::StrTab)
     Add(InX::StrTab);
 
   if (Config->EMachine == EM_ARM && !Config->Relocatable)
     // Add a sentinel to terminate .ARM.exidx. It helps an unwinder
     // to find the exact address range of the last entry.
     Add(make<ARMExidxSentinelSection>());
 }
 
+// Replace .[cd]tors sections with .{init,fini}_array sections.
+static void createInitFiniSections() {
+  for (size_t I = 0; I < InputSections.size(); ++I) {
+    InputSection *Sec = dyn_cast<InputSection>(InputSections[I]);
+    if (!Sec || !Sec->Live)
+      continue;
+
+    if (Sec->Name != ".ctors" && !Sec->Name.startswith(".ctors.") &&
+        Sec->Name != ".dtors" && !Sec->Name.startswith(".dtors."))
+      continue;
+
+    // As a special rule, .[cd]tors sections in crtbeginS.o or crtendS.o
+    // shouldn't be converted because the runtime expect them to be in the
+    // original section. This is ugly, but without this, the resulting
+    // exectuable would crash on startup.
+    if (Sec->Name == ".ctors" || Sec->Name == ".dtors") {
+      StringRef S = Sec->File->getName();
+      if (isCrtbegin(S) || isCrtend(S))
+        continue;
+    }
+
+    InputSections[I] = createInitFiniSection(Sec);
+  }
+}
+
 // The main function of the writer.
 template <class ELFT> void Writer<ELFT>::run() {
   // Create linker-synthesized sections such as .got or .plt.
   // Such sections are of type input section.
   createSyntheticSections<ELFT>();
 
   if (!Config->Relocatable)
     combineEhFrameSections<ELFT>();
 
+  // Convert .[cd]tors to .{init,fini}_array if needed.
+  if (Config->CtorsInInitArray)
+    createInitFiniSections();
+
   // We want to process linker script commands. When SECTIONS command
   // is given we let it create sections.
   Script->processSectionCommands();
 
   // Linker scripts controls how input sections are assigned to output sections.
   // Input sections that were not handled by scripts are called "orphans", and
   // they are assigned to output sections by the default rule. Process that.
   Script->addOrphanSections();

lld/test/ELF/ctors-in-init-array.s

+# REQUIRES: x86
+
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t.o
+
+# RUN: mkdir -p %t.dir
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux \
+# RUN:   %p/Inputs/ctors_dtors_priority1.s -o %t.dir/crtbeginS.o
+
+# RUN: ld.lld %t.o %t.dir/crtbeginS.o -o %t1.exe
+# RUN: llvm-objdump -s %t1.exe | FileCheck %s
+
+# RUN: ld.lld %t.o %t.dir/crtbeginS.o -o %t2.exe --no-ctors-in-init-array
+# RUN: llvm-objdump -s %t2.exe | FileCheck -check-prefix=CTORS %s
+
+.globl _start
+_start:
+  nop
+
+.section .ctors, "aw", @progbits
+  .quad 8
+.section .ctors.100, "aw", @progbits
+  .quad 2
+.section .ctors.005, "aw", @progbits
+  .quad 3
+.section .ctors, "aw", @progbits
+  .quad 7
+.section .ctors, "aw", @progbits
+  .quad 6
+
+.section .init_array.1, "aw", @init_array
+  .quad 1
+.section .init_array.65535, "aw", @init_array
+  .quad 4
+.section .init_array, "aw", @init_array
+  .quad 5
+
+.section .dtors, "aw", @progbits
+  .quad 0x18
+.section .dtors.100, "aw", @progbits
+  .quad 0x12
+.section .dtors.005, "aw", @progbits
+  .quad 0x13
+.section .dtors, "aw", @progbits
+  .quad 0x17
+.section .dtors, "aw", @progbits
+  .quad 0x16
+
+.section .fini_array.1, "aw", @fini_array
+  .quad 0x11
+.section .fini_array.65535, "aw", @fini_array
+  .quad 0x14
+.section .fini_array, "aw", @fini_array
+  .quad 0x15
+
+# CHECK:      Contents of section .init_array:
+# CHECK-NEXT: 202000 01000000 00000000 02000000 00000000
+# CHECK-NEXT: 202010 03000000 00000000 04000000 00000000
+# CHECK-NEXT: 202020 05000000 00000000 06000000 00000000
+# CHECK-NEXT: 202030 07000000 00000000 08000000 00000000
+
+# CHECK:      Contents of section .fini_array:
+# CHECK-NEXT: 202040 11000000 00000000 12000000 00000000
+# CHECK-NEXT: 202050 13000000 00000000 14000000 00000000
+# CHECK-NEXT: 202060 15000000 00000000 16000000 00000000
+# CHECK-NEXT: 202070 17000000 00000000 18000000 00000000
+
+# CHECK:      Contents of section .ctors:
+# CHECK-NEXT: 202080 a1000000 00000000
+
+# CHECK:      Contents of section .dtors:
+# CHECK-NEXT: 202088 a2000000 00000000
+
+# CTORS:      Contents of section .ctors:
+# CTORS-NEXT: 202000 a1000000 00000000 08000000 00000000
+# CTORS-NEXT: 202010 07000000 00000000 06000000 00000000
+# CTORS-NEXT: 202020 03000000 00000000 02000000 00000000
+
+# CTORS:      Contents of section .init_array:
+# CTORS-NEXT: 202030 01000000 00000000 04000000 00000000
+# CTORS-NEXT: 202040 05000000 00000000
+
+# CTORS:      Contents of section .dtors:
+# CTORS-NEXT: 202048 a2000000 00000000 18000000 00000000
+# CTORS-NEXT: 202058 17000000 00000000 16000000 00000000
+# CTORS-NEXT: 202068 13000000 00000000 12000000 00000000
+
+# CTORS:      Contents of section .fini_array:
+# CTORS-NEXT: 202078 11000000 00000000 14000000 00000000
+# CTORS-NEXT: 202088 15000000 00000000

lld/test/ELF/ctors_dtors_priority.s

 // RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t1
 // RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux \
 // RUN:   %p/Inputs/ctors_dtors_priority1.s -o %t-crtbegin.o
 // RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux \
 // RUN:   %p/Inputs/ctors_dtors_priority2.s -o %t2
 // RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux \
 // RUN:   %p/Inputs/ctors_dtors_priority3.s -o %t-crtend.o
-// RUN: ld.lld %t1 %t2 %t-crtend.o %t-crtbegin.o -o %t.exe
+// RUN: ld.lld --no-ctors-in-init-array %t1 %t2 %t-crtend.o %t-crtbegin.o -o %t.exe
 // RUN: llvm-objdump -s %t.exe | FileCheck %s
 // REQUIRES: x86
 
 .globl _start
 _start:
   nop
 
 .section .ctors, "aw", @progbits

lld/test/ELF/gc-sections.s

 # REQUIRES: x86
 
 # RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t
-# RUN: ld.lld %t -o %t2
+# RUN: ld.lld --no-ctors-in-init-array %t -o %t2
 # RUN: llvm-readobj -sections -symbols %t2 | FileCheck -check-prefix=NOGC %s
-# RUN: ld.lld --gc-sections %t -o %t2
+# RUN: ld.lld --no-ctors-in-init-array --gc-sections %t -o %t2
 # RUN: llvm-readobj -sections -symbols %t2 | FileCheck -check-prefix=GC1 %s
-# RUN: ld.lld --export-dynamic --gc-sections %t -o %t2
+# RUN: ld.lld --no-ctors-in-init-array --export-dynamic --gc-sections %t -o %t2
 # RUN: llvm-readobj -sections -symbols %t2 | FileCheck -check-prefix=GC2 %s
 
 # NOGC: Name: .eh_frame
 # NOGC: Name: .text
 # NOGC: Name: .init
 # NOGC: Name: .fini
 # NOGC: Name: .ctors
 # NOGC: Name: .dtors