Support dead-stripping in ELF objects

[Michael Spencer]

On Mon, Apr 8, 2013 at 12:17 PM, Robinson, Paul <
Paul_Robinson at playstation.sony.com> wrote:

> > * 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.


I moved this over to SHF_SUBSECTIONS_VIA_SYMBOLS so that SHF_ATOMIZED can
be enabled by default.


> > * 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.
>

Yep, this is part of what I was trying to require.

The debug relocations are like this because of how DWARF works. I'll have
to look into it more for how to properly solve this. MachO avoids this
problem because it doesn't link debug info, so the section offsets are
still valid.


>
> >
> > * 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.
>

Yes.


>
>
> 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;
>

This is a much larger issue. We can fix it later. Just document it.


> - 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...
>

SectionKind::is{Text,Data{Rel,RelLocal,NoRel},ReadOnlyWithRel{,Local}}() ?


>
> 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
>

I'm not sure how to pick which bits LLVM should use. For now we can add
some bits to MCSectionELF that backends can use to choose what to emit.

We'll also need to add 3 single letter flags for the assembly syntax.
atomi(z)e, subsections_(v)ia_symbols, (d)eadstrip?

- Michael Spencer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130408/f5d79525/attachment.html>