Skip to content
Commit 5c4bbc27 authored by Fangrui Song's avatar Fangrui Song
Browse files

[ELF] Allow placing non-string SHF_MERGE sections with different alignments...

[ELF] Allow placing non-string SHF_MERGE sections with different alignments into the same MergeSyntheticSection

The difference from D63432/r365015 is that this patch does not place
SHF_STRINGS sections with different alignments into the same
MergeSyntheticSection. Doing that would:

(1) create unnecessary padding and thus waste space.
  Add a test tail-merge-string-align2.s to check no extra padding is created.
(2) make some input sections unaligned when tail merge (-O2) is enabled.
  The alignment of MergeTailAlignment::Builder was out of sync in D63432.
  MOVAPS on such unaligned strings can raise SIGSEGV.

This should fix PR42289: the Linux kernel has a use case that input
files have .rodata.cst32 sections with different alignments. The
expectation (and what ld.bfd and gold do) is that in the -r link, there
is only one .rodata.cst32 (SHF_MERGE sections with different alignments
can be combined), but lld currently creates one for each different
alignment.

The current merging strategy:

1) Group SHF_MERGE sections by (name, sh_flags, sh_entsize and
   sh_addralign). Merging is performed among a group, even if -O0 is specified.
2) Create one output section for each group. This is a special case in
   addInputSec().

This patch changes 1) to:

1) Group SHF_MERGE sections by (name, sh_flags, sh_entsize).
   Merging is performed among a group, even if -O0 is specified.

We will thus create just one .rodata.cst32 . This also improves merging
efficiency when sections with the same name but different alignments are
combined.

Reviewed By: peter.smith

Differential Revision: https://reviews.llvm.org/D64200

llvm-svn: 365139
parent 146f1f2e
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment