Support dead-stripping in ELF objects

[Robinson, Paul]

> * SHF_ATOMIZED
>  This is important to be able to be alone for performance reasons. All
> current code can use this without breaking, even if it makes assumptions
> about the ABI. It's just letting the linker know that the compiler did
> what the compiler almost always does, which is give correct symbol sizes.

This is a weaker statement than you gave previously, where you specified
that it also means relocation addends do not cross symbol boundaries.
I assume you still want the relocation restrictions, which tells the linker
that the symbols define proper atoms.  Having correct sizes all by itself
does not tell you that.

> * SHF_SUBSECTIONS_VIA_SYMBOLS
>  Alone this is not very useful. But it's important for SHF_ATOMIZED to be
> not tied to this for compatibility reasons.

Yeah, I even thought of a use case for atomized-but-not-subsections:
In a code section, if control can fall through from one atom to the next,
obviously the atoms can't be rearranged.  Can happen in hand-coded assembler,
or in a language with alternate entry points to the same function (I think
FORTRAN permits this, of the languages known to use LLVM).

It is possible you want SHF_SUBSECTIONS_VIA_SYMBOLS to add another constraint
on relocations:

* If any relocation has a target symbol which is defined in a section with
  this flag set, that symbol must not have type STT_SECTION.

That is, every relocation targeting this section will use an atom-base
symbol, not .section+N relocations.  My patch does not fully achieve this
effect, some relocations from .debug_info to .text are still in .text+N
form.  My toolchain doesn't care because when we're dead-stripping, we
don't care about .debug_info anyway, but it suggests something slipped
through the cracks that you might care about.

>
> * SHF_DEADSTRIP
>  This is important in cases where you care about code size, especially on
> platforms where relaxation can greatly shrink code size, but you still want
> to remove entirely dead sections. This is based on -f{function,data}-sections
> + --gc-sections generating a larger binary in practice than just --gc-sections
> in cases where most code is not dead. It's also important for this to be per
> section instead of a linker flag because not all sections can be removed if
> not referenced. The alternative is keeping a hard coded list of special
> sections in the linker, which is what we do now.

Just to verify, SHF_DEADSTRIP means the linker can trash the section as a
whole, and SHF_DEADSTRIP+SHF_SUBSECTIONS_VIA_SYMBOLS means the linker can
trash individual subsections.


So, getting back to my actual patch, there are two things it would need:
- if you care about relocations from .debug_info following the subsection
  rules, then I need to track down why I still get .text+N for those;
- and somehow I'd need to arrange to set these three new section flags on
  the right sections. Seems clear they would not go on all sections...

Oh, and figure out which bits to use for the new flags, that won't
interfere with anybody else's section-flag bits.

Thanks,
--paulr