ALHP
/
ALHP.GO
6
34
Fork 9
Code Issues 29 Pull Requests Projects Releases Wiki Activity

Use RELR relative relocations to reduce file sizes (-z pack-relative-relocs) #134

New Issue
Closed
opened 2022-08-04 23:26:05 +02:00 by BertalanD · 9 comments
BertalanD commented 2022-08-04 23:26:05 +02:00
Contributor
Copy Link

In binutils 2.38 and the recently released glibc 2.36, support has been added for the DT_RELR relative relocation format. This format can significantly reduce the size of shared libraries and position-independent executables. Measurements show a 5% decrease in size for libraries, and 8% for executables in total.

One particular measurement, taken from MaskRay's Arch feature request (https://bugs.archlinux.org/task/72433):

 % ~/projects/bloaty/Release/bloaty clang.pie.relr -- clang.pie
   FILE SIZE        VM SIZE    
 --------------  -------------- 
  [NEW]  +163Ki  [NEW]  +163Ki    .relr.dyn
  +4.9%     +32  +5.4%     +32    .dynamic
  +2.5%      +8  [ = ]       0    .shstrtab
 -99.5% -13.8Mi -99.5% -13.8Mi    .rela.dyn
  -8.3% -13.6Mi  -8.2% -13.6Mi    TOTAL

This great blog post explains the technical details: https://maskray.me/blog/2021-10-31-relative-relocations-and-relr. It highlights that RELR been used (with patched binutils+libc) in ChromeOS/Android for a long time without any issues. User applications don't need to adapt to the new format.

To enable RELR, the -z pack-relative-relocs flag must be passed to GNU ld. With LLD/mold, the --pack-dyn-relocs=relr spelling should be used instead.

In binutils 2.38 and the recently released glibc 2.36, support has been added for the `DT_RELR` relative relocation format. This format can significantly reduce the size of shared libraries and position-independent executables. Measurements show a 5% decrease in size for libraries, and 8% for executables in total. One particular measurement, taken from MaskRay's Arch feature request (https://bugs.archlinux.org/task/72433): > ``` > % ~/projects/bloaty/Release/bloaty clang.pie.relr -- clang.pie > FILE SIZE VM SIZE > -------------- -------------- > [NEW] +163Ki [NEW] +163Ki .relr.dyn > +4.9% +32 +5.4% +32 .dynamic > +2.5% +8 [ = ] 0 .shstrtab > -99.5% -13.8Mi -99.5% -13.8Mi .rela.dyn > -8.3% -13.6Mi -8.2% -13.6Mi TOTAL > ``` This great blog post explains the technical details: https://maskray.me/blog/2021-10-31-relative-relocations-and-relr. It highlights that RELR been used (with patched binutils+libc) in ChromeOS/Android for a long time without any issues. User applications don't need to adapt to the new format. To enable RELR, the `-z pack-relative-relocs` flag must be passed to GNU ld. With LLD/mold, the `--pack-dyn-relocs=relr` spelling should be used instead.
👍 2
anonfunc commented 2022-08-05 19:08:19 +02:00
Owner
Copy Link

Sounds interesting. As far as I understand, ALHP would need to detect the compiler/linker used, so that the correct flags are added? If so, this is probably blocked by #124.

Sounds interesting. As far as I understand, ALHP would need to detect the compiler/linker used, so that the correct flags are added? If so, this is probably blocked by #124.
BertalanD commented 2022-08-05 19:22:34 +02:00
Author
Contributor
Copy Link

LLD will get support for the GNU argument name in 15.0.0, whose is planned to be released on September 6th. If I remember correctly, mold does not support that spelling as of now; we could open a feature request. The only package that lists mold as its build dependency is cardinal. The only remaining linker is GNU gold, but I hope there aren't any projects depending on it in 2022...

Sidenote: it's a bit infuriating that the binutils maintainers decided to go with a custom spelling instead of the one established by the original implementation in LLD.

Do you have any examples of packages that override the default linker?

LLD will get support for the GNU argument name in 15.0.0, whose is planned to be released on September 6th. If I remember correctly, `mold` does not support that spelling as of now; we could open a feature request. The only package that lists mold as its build dependency is `cardinal`. The only remaining linker is GNU gold, but I hope there aren't any projects depending on it in 2022... Sidenote: it's a bit infuriating that the binutils maintainers decided to go with a custom spelling instead of the one established by the original implementation in LLD. Do you have any examples of packages that override the default linker?
anonfunc commented 2022-08-05 19:58:55 +02:00
Owner
Copy Link

LLD will get support for the GNU argument name in 15.0.0, whose is planned to be released on September 6th. If I remember correctly, mold does not support that spelling as of now; we could open a feature request. The only package that lists mold as its build dependency is cardinal. The only remaining linker is GNU gold, but I hope there aren't any projects depending on it in 2022...

Gold is most likely not worth talking about, no. So, best case scenario would be to wait until that new LLD release, then add -z pack-relative-relocs, since this should be supported by LLD and ld by then.

Sidenote: it's a bit infuriating that the binutils maintainers decided to go with a custom spelling instead of the one established by the original implementation in LLD.

Do you have any examples of packages that override the default linker?

I quickly grep'd the PKGBUILD tree, and besides already mentioned cardinal, there appear to be none. cardinal, using mold, will most likely fail after adding that above mentioned flag, but adding one more package to the ignore list would not be that detrimental. Maybe we can, as you said, convince the mold devs to also accept the GNU flag.

> LLD will get support for the GNU argument name in 15.0.0, whose is planned to be released on September 6th. If I remember correctly, `mold` does not support that spelling as of now; we could open a feature request. The only package that lists mold as its build dependency is `cardinal`. The only remaining linker is GNU gold, but I hope there aren't any projects depending on it in 2022... Gold is most likely not worth talking about, no. So, best case scenario would be to wait until that new LLD release, then add `-z pack-relative-relocs`, since this should be supported by LLD and ld by then. > > Sidenote: it's a bit infuriating that the binutils maintainers decided to go with a custom spelling instead of the one established by the original implementation in LLD. > > Do you have any examples of packages that override the default linker? I quickly grep'd the PKGBUILD tree, and besides already mentioned `cardinal`, there appear to be none. `cardinal`, using mold, will most likely fail after adding that above mentioned flag, but adding one more package to the ignore list would not be that detrimental. Maybe we can, as you said, convince the mold devs to also accept the GNU flag.
anonfunc added the
enhancement
blocked upstream
 labels 2022-08-05 20:10:40 +02:00
anonfunc commented 2023-06-03 13:57:48 +02:00
Owner
Copy Link

@BertalanD How is the status here? Are we still waiting for upstream? I see some of the versions you mentioned are already released now.

@BertalanD How is the status here? Are we still waiting for upstream? I see some of the versions you mentioned are already released now.
BertalanD commented 2023-06-03 14:09:08 +02:00
Author
Contributor
Copy Link

It looks like we should be good to go.

  • Mold supports the GNU-style -z pack-relative-relocs as of 1.7.0
  • LLVM 15 has shipped a long time ago, it also supports the GNU-style spelling now
  • Relocation support is available in musl since version 1.2.4
  • Support in the GNU BFD linker and glibc was already available when I opened this issue
It looks like we should be good to go. - Mold [supports](https://github.com/rui314/mold/commit/b365d6ba1aade2e99d636892e4a21b8d7988a01c) the GNU-style `-z pack-relative-relocs` as of 1.7.0 - LLVM 15 has shipped a long time ago, it also [supports](https://github.com/llvm/llvm-project/commit/4a8de2832a2a730f63b71bdf1c1b446285ec5b6f) the GNU-style spelling now - Relocation support is [available](https://github.com/bminor/musl/commit/d32dadd60efb9d3b255351a3b532f8e4c3dd0db1) in musl since version 1.2.4 - Support in the GNU BFD linker and glibc was already available when I opened this issue
anonfunc removed the
blocked upstream
 label 2023-06-03 14:14:16 +02:00
anonfunc commented 2023-06-03 14:22:04 +02:00
Owner
Copy Link

Very nice. If I understood correctly -z,pack-relative-relocs has to be added to LDFLAGS?

Very nice. If I understood correctly `-z,pack-relative-relocs` has to be added to `LDFLAGS`?
BertalanD commented 2023-06-03 14:42:27 +02:00
Author
Contributor
Copy Link

It also needs the -Wl, prefix if the flag is separated by a space from the other linker flags.

It also needs the `-Wl,` prefix if the flag is separated by a space from the other linker flags.
anonfunc commented 2023-06-03 14:48:51 +02:00
Owner
Copy Link

I'll try to add it without space, but I think I need to adjust the flag parsing logic for LDFLAGS, because of the different separation.

I'll try to add it without space, but I think I need to adjust the flag parsing logic for `LDFLAGS`, because of the different separation.
anonfunc commented 2023-06-03 15:33:55 +02:00
Owner
Copy Link

I made the necessary changes. Should be active from now on 👍

I made the necessary changes. Should be active from now on 👍
❤️ 1
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
Labels
Clear labels   
blocked upstream

   
bug

Something is not working

  
build-failure

package build fails because of our added buildflags

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
help wanted

Need some help

  
informational

Provides information about something

  
invalid

Something is wrong

  
invalid/corrupt package

Package needs to be rebuild

  
packaging issue

   
priority: high

High priority

  
question

More information is needed

  
support

   
wontfix

This won't be fixed

No Label
blocked upstream
bug
build-failure
duplicate
enhancement
help wanted
informational
invalid
invalid/corrupt package
packaging issue
priority: high
question
support
wontfix
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: ALHP/ALHP.GO#134
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?