Home Original page

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

Fangrui Song i@maskray.me
Tue Mar 3 02:03:00 GMT 2020 
On Mon, Mar 2, 2020 at 2:50 PM Alan Modra <amodra@gmail.com> wrote:
>
> 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.

For this case, foo may be a static function-local object in an inline function.
The symbol foo is defined in .data.rel.ro.foo and all its references
are via .toc
Thus I imagined that in the absence of GOT-generating relocations
(clang/GCC status quo),
placing .toc in the same section group can deduplicate TOC entries.

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

Thanks for the confirmation that switching to @got may be beneficial.
Is there any drawback? I spend very little of time contributing to
LLVM's PowerPC backend.
If you think @got is good, I'd like to investigate more.
I have barely any GCC commit and I will likely not contribute there.

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

Thanks for the confirmation. If compilers are generating TOC
relocations, then such ad-hoc garbage collection is unavoidable.
More information about the Binutils mailing list