x86_64-exception-multiple-ehframe fails with GCC 14

[marxin]

Fails with the following files:
objects.tar.gz

❯ g++ [bc].o -B.
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
compilation terminated.

$ gdb --args ./mold [bc].o
...
0x0000000000803ef8 in mold::elf::ObjectFile<mold::elf::X86_64>::initialize_symbols (this=this@entry=0x2cbc4150600, ctx=...) at /home/marxin/Programming/mold/elf/input-files.cc:586
586	      name = this->shstrtab.data() + this->elf_sections[get_shndx(esym)].sh_name;
(gdb) bt
#0  0x0000000000803ef8 in mold::elf::ObjectFile<mold::elf::X86_64>::initialize_symbols (this=this@entry=0x2cbc4150600, ctx=...) at /home/marxin/Programming/mold/elf/input-files.cc:586
#1  0x0000000000804883 in mold::elf::ObjectFile<mold::elf::X86_64>::parse (this=0x2cbc4150600, ctx=...) at /home/marxin/Programming/mold/elf/input-files.cc:943
#2  0x00000000009e9747 in operator() (__closure=0x2cbc4170640) at /home/marxin/Programming/mold/elf/main.cc:129
#3  tbb::detail::d2::(anonymous namespace)::task_ptr_or_nullptr<const mold::elf::new_object_file<X86_64>(Context<X86_64>&, mold::MappedFile*, std::string)::<lambda()>&> (f=...) at /home/marxin/Programming/mold/third-party/tbb/src/tbb/../../include/tbb/../oneapi/tbb/task_group.h:132
#4  tbb::detail::d1::function_task<mold::elf::new_object_file<X86_64>(Context<X86_64>&, mold::MappedFile*, std::string)::<lambda()> >::execute(tbb::detail::d1::execution_data &) (this=0x2cbc4170600, ed=...) at /home/marxin/Programming/mold/third-party/tbb/src/tbb/../../include/tbb/../oneapi/tbb/task_group.h:452
#5  0x0000000001398de3 in tbb::detail::r1::task_dispatcher::local_wait_for_all<false, tbb::detail::r1::external_waiter> (waiter=..., t=<optimized out>, this=<optimized out>) at /home/marxin/Programming/mold/third-party/tbb/src/tbb/task_dispatcher.h:323
#6  tbb::detail::r1::task_dispatcher::local_wait_for_all<tbb::detail::r1::external_waiter> (waiter=..., t=<optimized out>, this=<optimized out>) at /home/marxin/Programming/mold/third-party/tbb/src/tbb/task_dispatcher.h:459
#7  tbb::detail::r1::task_dispatcher::execute_and_wait (t=t@entry=0x0, wait_ctx=..., w_ctx=...) at /home/marxin/Programming/mold/third-party/tbb/src/tbb/task_dispatcher.cpp:168
#8  0x000000000139953d in tbb::detail::r1::wait (wait_ctx=..., w_ctx=...) at /home/marxin/Programming/mold/third-party/tbb/src/tbb/task_dispatcher.cpp:126
#9  0x00000000009f3feb in tbb::detail::d1::wait (ctx=..., wait_ctx=...) at /home/marxin/Programming/mold/third-party/tbb/src/tbb/../../include/tbb/../oneapi/tbb/detail/_task.h:197
#10 tbb::detail::d1::task_group_base::wait()::{lambda()#1}::operator()() const (__closure=<optimized out>) at /home/marxin/Programming/mold/third-party/tbb/src/tbb/../../include/tbb/../oneapi/tbb/task_group.h:582
#11 tbb::detail::d0::try_call_proxy<tbb::detail::d1::task_group_base::wait()::{lambda()#1}>::on_completion<tbb::detail::d1::task_group_base::wait()::{lambda()#2}>(tbb::detail::d1::task_group_base::wait()::{lambda()#2}) (on_completion_body=..., this=<optimized out>)
    at /home/marxin/Programming/mold/third-party/tbb/src/tbb/../../include/tbb/../oneapi/tbb/detail/_template_helpers.h:230
#12 tbb::detail::d1::task_group_base::wait (this=0x7fffffffcbb0) at /home/marxin/Programming/mold/third-party/tbb/src/tbb/../../include/tbb/../oneapi/tbb/task_group.h:583
#13 mold::elf::read_input_files<mold::elf::X86_64> (args=..., ctx=...) at /home/marxin/Programming/mold/elf/main.cc:340
#14 mold::elf::elf_main<mold::elf::X86_64> (argc=3, argv=<optimized out>) at /home/marxin/Programming/mold/elf/main.cc:403
#15 0x00007ffff782a1f0 in __libc_start_call_main () from /lib64/libc.so.6
#16 0x00007ffff782a2b9 in __libc_start_main_impl () from /lib64/libc.so.6
#17 0x000000000040e5b5 in _start () at ../sysdeps/x86_64/start.S:115

[marxin]

FYI: @andreas-schwab

[rui314]

Could you also share a.o?

[marxin]

Sure:
a.o.tar.gz

[rui314]

Does the above change work for you?

[marxin]

Yes, it did.

Anyway, I don't think objcopy corrupted the ELF container, but instead the sections are in the opposite order if I compare objdump -s out/test/elf/x86_64/exception-multiple-ehframe/c.o before and after your change:

 Contents of section .note.gnu.property:
  0000 04000000 10000000 05000000 474e5500  ............GNU.
  0010 010001c0 04000000 01000000 00000000  ................
 Contents of section .eh_frame:
  0000 1c000000 00000000 017a504c 52000178  .........zPLR..x
  0010 10079b00 0000001b 1b0c0708 90010000  ................
  0020 24000000 24000000 00000000 5b000000  $...$.......[...
  0030 04000000 00410e10 8602430d 06458303  .....A....C..E..
- 0040 02510c07 08000000                    .Q......        
+ 0040 02510c07 08000000 00000000           .Q..........    
 Contents of section .eh_frame:
  0000 1c000000 00000000 017a504c 52000178  .........zPLR..x
  0010 10079b00 0000001b 1b0c0708 90010000  ................
  0020 24000000 24000000 00000000 5b000000  $...$.......[...
  0030 04000000 00410e10 8602430d 06458303  .....A....C..E..
- 0040 02510c07 08000000 00000000           .Q..........    
+ 0040 02510c07 08000000                    .Q......        
 Contents of section .gcc_except_table:
  0000 ff9b1101 082b0530 01390500 00010000  .....+.0.9......
  0010 00000000 ff9b1101 082b0530 01390500  .........+.0.9..
  0020 00010000 00000000                    ........        

[marxin]

Can we please reopen it?

[andreas-schwab]

sed is only guaranteed to work on text files.

[rui314]

objcopy indeed corrupted the ELF file because the tool created section symbols as absolute symbols, which doesn't make sense.

[marxin]

Can you try llvm-objcopy if it does the same?

[rui314]

I'll use perl instead of sed to modify the binary files.