* [PowerPC] Garbage collecting .toc entries in a non-adhoc way (section group)
@ 2020-03-02 6:56 Fangrui Song
2020-03-02 10:59 ` Alan Modra
0 siblings, 1 reply; 6+ messages in thread
From: Fangrui Song @ 2020-03-02 6:56 UTC (permalink / raw)
To: binutils; +Cc: Alan Modra
Originally described at https://reviews.llvm.org/D75416#1900281
.text.foo (SHF_GROUP) references .toc
.toc references .rodata.foo (SHF_GROUP)
If .text.foo and .rodata.foo are not prevailing (discarded by the section group rule) =>
.toc referencing .rodata.foo (STB_LOCAL) is disallowed by the ELF spec (http://www.sco.com/developers/gabi/latest/ch4.sheader.html):
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.
One fix is to let .toc reference foo (STB_GLOBAL/STB_WEAK) instead of .rodata.foo . STB_GLOBAL/STB_WEAK are allowed by the ELF spec.
There is still one problem: the .toc entry is not garbage collected. Well, ld can do it, but that will be an ad-hoc rule.
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.
One thought is to change the .toc reference to a STB_GLOBAL:
```
.text
addis 3,2,foo.toc@toc@ha
.section .toc,"aGw",@progbits,foo,comdat
.globl foo.toc
foo.toc:
.tc foo[TC],foo
```
Everything works fine except one thing: foo.toc is left in .symtab (unless --strip-all) and probably .dynsym. If we set the visibility of foo.toc to STB_HIDDEN or STB_INTERNAL, foo.toc will be omitted from .dynsym, but we cannot omit it from .symtab.
(Unless we extend ELF and say STB_INTERNAL symbols are omitted from .symtab, but this is may be bad/ad-hoc.)
I have a feeling that the `.tc` directive was misdesigned for ELF. If we let `foo@toc@ha` create a TOC entry implicitly (like a GOT-generating relocation on other architectures), we would not need multiple .toc sections in the first place.
Additionally, toc-indirect to toc-relative relaxation would become easier to implement.
Note, explicit `.section .toc,"aw",@progbits` can still be allowed if we want to emit some non-symbol entries.
They are explicit. The TOC relocation referenced symbols are implicit.
It is sad that .toc is prettier than ppc32 .got2, but that is the pot calling the kettle black.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PowerPC] Garbage collecting .toc entries in a non-adhoc way (section group)
2020-03-02 6:56 [PowerPC] Garbage collecting .toc entries in a non-adhoc way (section group) Fangrui Song
@ 2020-03-02 10:59 ` Alan Modra
2020-03-02 18:03 ` Fangrui Song
0 siblings, 1 reply; 6+ messages in thread
From: Alan Modra @ 2020-03-02 10:59 UTC (permalink / raw)
To: Fangrui Song; +Cc: binutils
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.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PowerPC] Garbage collecting .toc entries in a non-adhoc way (section group)
2020-03-02 10:59 ` Alan Modra
@ 2020-03-02 18:03 ` Fangrui Song
2020-03-02 22:50 ` Alan Modra
0 siblings, 1 reply; 6+ messages in thread
From: Fangrui Song @ 2020-03-02 18:03 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PowerPC] Garbage collecting .toc entries in a non-adhoc way (section group)
2020-03-02 18:03 ` Fangrui Song
@ 2020-03-02 22:50 ` Alan Modra
2020-03-03 2:03 ` Fangrui Song
0 siblings, 1 reply; 6+ messages in thread
From: Alan Modra @ 2020-03-02 22:50 UTC (permalink / raw)
To: Fangrui Song; +Cc: binutils
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PowerPC] Garbage collecting .toc entries in a non-adhoc way (section group)
2020-03-02 22:50 ` Alan Modra
@ 2020-03-03 2:03 ` Fangrui Song
2020-03-04 1:25 ` Alan Modra
0 siblings, 1 reply; 6+ messages in thread
From: Fangrui Song @ 2020-03-03 2:03 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PowerPC] Garbage collecting .toc entries in a non-adhoc way (section group)
2020-03-03 2:03 ` Fangrui Song
@ 2020-03-04 1:25 ` Alan Modra
0 siblings, 0 replies; 6+ messages in thread
From: Alan Modra @ 2020-03-04 1:25 UTC (permalink / raw)
To: Fangrui Song; +Cc: binutils
On Mon, Mar 02, 2020 at 06:02:41PM -0800, Fangrui Song wrote:
> Thanks for the confirmation that switching to @got may be beneficial.
> Is there any drawback?
The TOC scheme may give better locality of reference and thus better
cache performance. The TOC layout is under control of the compiler,
which generally has better information about data access patterns than
the linker. Mind you, powerpc gcc doesn't really do anything about
optimising the TOC, but it would be possible.
> If you think @got is good
Yes, I do.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-03-04 1:25 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-02 6:56 [PowerPC] Garbage collecting .toc entries in a non-adhoc way (section group) Fangrui Song
2020-03-02 10:59 ` Alan Modra
2020-03-02 18:03 ` Fangrui Song
2020-03-02 22:50 ` Alan Modra
2020-03-03 2:03 ` Fangrui Song
2020-03-04 1:25 ` Alan Modra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).