[PowerPC] Garbage collecting .toc entries in a non-adhoc way (section group)

[Alan Modra]

On Mon, Mar 02, 2020 at 10:02:43AM -0800, Fangrui Song wrote:
> On Mon, Mar 2, 2020 at 2:59 AM Alan Modra <amodra@gmail.com> wrote:
> >
> > On Sun, Mar 01, 2020 at 10:56:02PM -0800, Fangrui Song wrote:
> > > Now I am thinking about whether we can produce .toc in section groups to obtain garbage collection ability for free.
> > >
> > > .text (not in a section group) references `foo` defined in .data.rel.ro.foo (in a section group) via .toc .
> > > ```
> > > .text
> > > addis 3,2,.LC0@toc@ha
> > >
> > > .section .data.rel.ro.foo,"aGw",foo,comdat
> > > .globl foo
> > > foo:
> > >
> > > .section .toc,"aGw",@progbits,foo,comdat
> > > .LC0:
> > > .tc foo[TC],foo
> > > ```
> > >
> > > When `.data.rel.ro.foo` and the `.toc` are discarded due to the section
> > > group rule, the relocation from `.text` to the `.toc` becomes dangling.
> >
> > Yes, that breaks the ELF gABI which says: "A symbol table entry with
> > STB_LOCAL binding that is defined relative to one of a group's
> > sections, and that is contained in a symbol table section that is not
> > part of the group, must be discarded if the group members are
> > discarded.  References to this symbol table entry from outside the
> > group are not allowed."
> >
> > I think what you're trying to do is reinvent the GOT.  There isn't any
> > reason why powerpc64 can't use a GOT and GOT relocations.
> 
> Yes, there is inventing the GOT. But neither GCC nor clang produces
> foo@got@ha and foo@got@l pairs. Is there some hidden wisdom I am
> missing?

Normally a section group contains related information that a compiler
generates for something, for example, a function.  Comdat groups are
used for things like out-of-line definitions of inline functions where
only one copy of the function should be kept.  You seem to be turning
this idea on its head, trying to generate groups for references *to* a
function.  That quite obviously can't work in general, because all the
groups generated with a particular signature in a program should
contain the same information: Any one of the groups can be kept by
the linker.  That means references to external functions can't be
placed in a group with the same signature as the function.

So your scheme could only work for functions where you have a local
definition of the function.  Which is surely not a huge percentage of
.toc addresses.  And if you're making compiler changes, why not go all
the way and change gcc or clang to generate @got references?  The
relocs are available, and BFD ld at least should handle them.

Incidentally, BFD ld edits the toc to remove unused entries.

-- 
Alan Modra
Australia Development Lab, IBM