public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Fangrui Song <i@maskray.me>
To: binutils@sourceware.org
Cc: Alan Modra <amodra@gmail.com>
Subject: [PowerPC] Garbage collecting .toc entries in a non-adhoc way (section group)
Date: Mon, 02 Mar 2020 06:56:00 -0000	[thread overview]
Message-ID: <20200302065602.jtyhq5wkhmz5kqh2@gmail.com> (raw)

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.

             reply	other threads:[~2020-03-02  6:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-02  6:56 Fangrui Song [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200302065602.jtyhq5wkhmz5kqh2@gmail.com \
    --to=i@maskray.me \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).