Created attachment 10924 [details]
tar file containing C sources, makefile

The code in the gold linker that handles relocatable links seems to be having problems when there are a mix of input object files from GCC and Clang (x86_64), in some cases triggering an assert.

Given two C source files (contents unimportant, but each should have at least one function), bug can be triggered by running the following commands:

  gcc -fPIC -g -O2 -c this.c
  clang -fPIC -g -O2 -c other.c
  gcc -fuse-ld=gold  -fPIC -g -O2  -Wl,-r -nostdlib -no-pie this.o other.o -o rel.o

resulting in this assert:

  ld.gold: internal error in set_info_section, at ../../binutils/gold/output.h:3386

I've reproduced this on linux x86_64 with several versions of clang, gcc, and ld.gold (including top of trunk for each). GCC 7 + clang 3.9 + gold 1.15 is one starting point.

Stack trace for the assert looks like:

#0  gold::Output_section::set_info_section (this=0x<...> os=0x<...> at ../../binutils/gold/output.h:3382
#1  0x<...> in gold::Layout::layout_reloc<64, false> (this=0x<...> object=0x<...> shdr=..., data_section=0x<...> rr=0x<...> at ../../binutils/gold/layout.cc:1354
#2  0x<...> in gold::Sized_relobj_file<64, false>::do_layout (this=0x<...> symtab=0x<...> layout=0x<...> sd=0x<...> at ../../binutils/gold/object.cc:1856
#3  0x<...> in gold::Object::layout (this=0x<...> symtab=0x<...> layout=0x<...> sd=0x<...> at ../../binutils/gold/object.h:651
#4  0x<...> in gold::Add_symbols::run (this=0x<...> at ../../binutils/gold/readsyms.cc:634
#5  0x<...> in gold::Workqueue::find_and_run_task (this=0x<...> thread_number=0) at ../../binutils/gold/workqueue.cc:319
#6  0x<...> in gold::Workqueue::process (this=0x<...> thread_number=0) at ../../binutils/gold/workqueue.cc:495
#7  0x<...> in main (argc=6, argv=0x<...> at ../../binutils/gold/main.cc:252

The relocation section being laid out at the point of the assert is one of the .rela.eh_frame sections. 

When I look at the gcc-compiled objects feeding into the link, I see .eh_frame sections that look like:

  [ 7] .eh_frame
       PROGBITS        0000000000000000 000088 000038 00   0   0  8
       [0000000000000002]: ALLOC
  [ 8] .rela.eh_frame
       RELA            0000000000000000 0001e0 000018 18   9   7  8
       [0000000000000040]: INFO LINK

The corresponding sections from LLVM-backend compiled objects look like

  [16] .eh_frame
       X86_64_UNWIND   0000000000000000 0001e8 000030 00   0   0  8
       [0000000000000002]: ALLOC
  [17] .rela.eh_frame
       RELA            0000000000000000 000470 000018 18  20  16  8
       [0000000000000000]:

Note the section types -- this seems to be the crux of the problem. LLVM (as of 2013 or so) sets the section type to X86_64_UNWIND, not PROGBITS. The X86_64 ps-ABI recommends using this section type, but not all producers do (gcc does not).

Googling assert in question turns up a few other instances, including:

  https://stackoverflow.com/questions/47797817/ld-gold-internal-error-in-set-info-section-at-output-h3209
  https://sourceware.org/bugzilla/show_bug.cgi?id=15861

however it's not clear whether this is the same bug (some of the instances out in the wild seem to involve the use of a linker script).

I spent a while in the debugger looking at what is happening. When gold processes the two different .eh_frame sections, it effectively treats them as distinct sections in the output file (since output section lookup is based on name, type, and flags). In the case of the .rela.eh_frame sections, however, we get only a single output section (since both input ".rela.eh_frame" sections have the same name/type/flags). The assert is happening when Layout::layout_reloc is called on the second relocation section. The code looks like:

    gold_assert((this->info_section_ == NULL
		 || (this->info_section_ == os
		     && this->info_uses_section_index_))
		&& this->info_symndx_ == NULL
		&& this->info_ == 0);

Here "info_section_" is already pointing to the first output section for .eh_frame, however we're trying to set it to the second output section.

I have been experimenting with fixes.  I note that for non-relocatable links, gold is already effectively merging PROGBITS + X86_64_UNWIND .eh_frame sections into a single merged PROGBITS section (see the "FIXME" comment in Layout::make_eh_frame_section).  With this in mind, a similar way to solve the problem would be to do the same merging for relocatable links. 

A patch to do this appears below; this fixes the assert.

A second possibility would be to change things so that the two separate "flavors" of .eh_frame section are preserved in the output object for relocatable links, meaning that there would have to be two separate relocation sections as well. This would mean special handling of some sort when creating output sections for .rela.eh_frame sections (e.g. not just calling Layout::choose_output_section).

I am attaching a reproducer; unpack the tar file and run "make" (may need to edit the makefile so that correct gcc and clang paths are picked up). Ex:

$ make THISCC=gcc-7 OTHERCC=clang-3.9 all
gcc-7 -fPIC -g -O2 -c this.c
clang-3.9 -fPIC -g -O2 -c other.c
gcc-7 -fuse-ld=gold  -fPIC -g -O2 -Wl,-r -nostdlib -no-pie this.o other.o -o rel.o 
/usr/bin/ld.gold: internal error in set_info_section, at ../../gold/output.h:3386
collect2: error: ld returned 1 exit status
makefile:19: recipe for target 'rel.o' failed
make: *** [rel.o] Error 1
$

-----

Tentative patch:

diff --git a/gold/layout.cc b/gold/layout.cc
index f5fe805ea..987e12092 100644
--- a/gold/layout.cc
+++ b/gold/layout.cc
@@ -829,6 +829,13 @@ Layout::get_output_section(const char* name, Stringpool::Key name_key,
       || lookup_type == elfcpp::SHT_PREINIT_ARRAY)
     lookup_type = elfcpp::SHT_PROGBITS;
 
+  // Some compilers assign a type of SHT_PROGBITS to the .eh_frame
+  // section, while others use the psABI-recommended SHT_X86_64_UNWIND.
+  // Insure that we combine the two in the resulting output file (mainly
+  // an issue for relocatable links).
+  if (lookup_type == elfcpp::SHT_X86_64_UNWIND)
+    lookup_type = elfcpp::SHT_PROGBITS;
+
   elfcpp::Elf_Xword lookup_flags = flags;
 
   // Ignoring SHF_WRITE and SHF_EXECINSTR here means that we combine