commit f3d3b4d50a33fc279e6e600901f19f9311ea7f9b
author Fangrui Song <i@maskray.me> Wed Nov 01 22:35:28 2023 -0700
committer Copybara-Service <copybara-worker@google.com> Wed Nov 01 22:41:16 2023 -0700
tree f3334d3b1f0b7b275b3877392e0f11a4c6d6d453
parent c453e54930e8967b975096855a008cf3daa6cc25

[ELF] adjustOutputSections: don't copy SHF_EXECINSTR when an output does not contain input sections (#70911)

For an output section with no input section, GNU ld eliminates the
output section when there are only symbol assignments (e.g.
`.foo : { symbol = 42; }`) but not for `.foo : { . += 42; }`
(`SHF_ALLOC|SHF_WRITE`).

We choose to retain such an output section with a symbol assignment
(unless unreferenced `PROVIDE`). We copy the previous section flag (see
https://reviews.llvm.org/D37736) to hopefully make the current PT_LOAD
segment extend to the current output section:

* decrease the number of PT_LOAD segments
* If a new PT_LOAD segment is introduced without a page-size
  alignment as a separator, there may be a run-time crash.

However, this `flags` copying behavior is not suitable for
`.foo : { . += 42; }` when `flags` contains `SHF_EXECINSTR`. The
executable bit is surprising

(https://discourse.llvm.org/t/lld-output-section-flag-assignment-behavior/74359).

I think we should drop SHF_EXECINSTR when copying `flags`. The risk is a
code section followed by `.foo : { symbol = 42; }` will be broken, which
I believe is unrelated as such uses are almost always related to data
sections.

For data-command-only output sections (e.g. `.foo : { QUAD(42) }`), we
keep allowing copyable SHF_WRITE.

Some tests are updated to drop the SHF_EXECINSTR flag. GNU ld doesn't
set SHF_EXECINSTR as well, though it sets SHF_WRITE for some tests while
we don't.

GitOrigin-RevId: a40f651a065ef28fee17bc1f22cce08247eff950