[PATCH] ld: entry size and merge/strings attributes propagation

[Cary Coutant]

> As indicated in other recent commits, the three properties can be
> largely independent (ELF generally being the target here): Entry size
> doesn't require either of merge/strings, and strings also doesn't
> require merge. Commit 98e6d3f5bd4e ("gas/ELF: allow specifying entity
> size for arbitrary sections") uncovered issues with ld's handling.

This is true, but on the other hand, there's not much value in marking
a section SHF_STRINGS without also marking it SHF_MERGE. Sure, it's
legal and valid, but no tool I know of is going to do anything special
with a non-merge strings section.

> Zap entry size when it doesn't match between input sections. In that
> case SEC_MERGE and SEC_STRINGS also need to be removed, as their
> underlying granularity is lost. Then deal with SEC_MERGE and
> SEC_STRINGS separately.

Hopefully, merge sections with non-matching sh_entsize values is an
anomaly. We have section naming conventions (e.g., ".rodata.4") so
that the linker doesn't even try to combine non-matching sections. But
there's nowhere in the spec that requires that naming convention, and
there's nothing in the spec that disallows multiple output sections of
the same name, so an ambitious linker might choose to combine all the
merge sections with one sh_entsize into one output section (with
merging), and repeat for each additional value of sh_entsize. Once the
individual constant merging is complete, it could even combine the
merged output into a single output section (with sh_entsize set to 0),
or it could just leave each merged result as a separate output section
(with sh_entsize preserved).

Of course, nothing forces the linker to do that. It's also reasonable
to drop the merge flags and ignore sh_entsize.

-cary