unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Fangrui Song <maskray@gcc.gnu.org>
To: libc-alpha@sourceware.org
Subject: CREL dynamic relocations
Date: Sat, 23 Mar 2024 22:50:01 -0700	[thread overview]
Message-ID: <CAN30aBGYhw-3t60oc9k9ffHRJ62ue0Sa+TKY6aPWOgVHEkK8sg@mail.gmail.com> (raw)

I have proposed a compact relocation format CREL at
https://groups.google.com/g/generic-abi/c/yb0rjw56ORw/m/eiBcYxSfAQAJ
(previously named RELLEB).

CREL primarily targets static relocations, achieving significant .o
file size reduction for lld builds: 18.0% for x86-64/aarch64 and 34.3%
for riscv64.
CREL holds promise for dynamic relocations as well, surpassing
Android's packed relocation format.

* R_*_GLOB_DAT and R_*_JUMP_SLOT relocations can typically be encoded
with repeated 0x09 0x01 (when shift==3, offset++, symidx++).
* Absolute relocation (__cxa_pure_virtual@CXXABI_1.3 + 0) relocations
typically require just one byte (offset+=n)

While CREL's benefit for non-relative relocations is smaller than
RELR's optimizing for relative relocations, it still shines for
programs where non-relative relocations make up more than 5% of the
file size
(quite a few GUI libraries, probably due to C++ virtual tables).
We could even consider phasing out REL/RELA for new architectures in
favor of CREL.

I'd love to hear your feedback on CREL and hope someone might consider
implementing rtld support (and binutils support if you like that as
well:) )
https://sourceware.org/bugzilla/show_bug.cgi?id=31541

I've notified binutils and GCC folks at
https://sourceware.org/pipermail/binutils/2024-March/133153.html
("CREL relocation format for ELF (was: RELLEB)").

             reply	other threads:[~2024-03-24  5:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-24  5:50 Fangrui Song [this message]
2024-03-25 11:52 ` CREL dynamic relocations Florian Weimer
2024-03-25 18:51   ` Fangrui Song
  -- strict thread matches above, loose matches on Subject: below --
2024-04-09 15:32 Wilco Dijkstra
2024-04-11  2:41 ` Fangrui Song
2024-04-12 16:18   ` enh
2024-04-18  4:31     ` Fangrui Song

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

  List information: https://www.gnu.org/software/libc/involved.html

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

  git send-email \
    --in-reply-to=CAN30aBGYhw-3t60oc9k9ffHRJ62ue0Sa+TKY6aPWOgVHEkK8sg@mail.gmail.com \
    --to=maskray@gcc.gnu.org \
    --cc=libc-alpha@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).