Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate size of .rela.dyn section on Linux #76657

Closed
MichalStrehovsky opened this issue Oct 5, 2022 · 5 comments
Closed

Investigate size of .rela.dyn section on Linux #76657

MichalStrehovsky opened this issue Oct 5, 2022 · 5 comments
Labels
area-NativeAOT-coreclr help wanted [up-for-grabs] Good issue for external contributors
Milestone

Comments

@MichalStrehovsky
Copy link
Member

It seems like this section contributes significantly to the size of the output executable on Linux (20+% of the image size).

For reference, relocations on NativeAOT/Windows accounts for only about 2% of the image size.

We should investigate whether we're doing something wrong/what can we do about it.

@MichalStrehovsky MichalStrehovsky added help wanted [up-for-grabs] Good issue for external contributors area-NativeAOT-coreclr labels Oct 5, 2022
@MichalStrehovsky MichalStrehovsky added this to the 8.0.0 milestone Oct 5, 2022
@filipnavara
Copy link
Member

I'll have a peek at this.

@MichalStrehovsky
Copy link
Member Author

MichalStrehovsky commented Nov 4, 2022

This section is to support pointer-sized relocations. Apparently a reloc on Linux costs like 24 bytes of metadata (vs ~2 bytes on Windows).

I'm working on a change to remove a bunch of them in perf critical parts that we want to keep pointer-sized relocations in.

I'll leave some that we should just change to 32bit relative relocs because there's no good reason to use pointer-size:

There's some that need to keep pointer-size relocs but cannot be switched to the new plan right away:

@filipnavara
Copy link
Member

Couple of random notes:

  • On x64 it would likely be possible to emit the .rel section instead of .rela and store the addends in the data. That can save a couple of bytes per record. On ARM64 this would be problematic for some types of relocations where the addend cannot be expressed (eg. IMAGE_REL_BASED_ARM64_PAGEBASE_REL21/IMAGE_REL_BASED_ARM64_PAGEOFFSET_12A).
  • Currently ObjWriter emits two different types of 32-bit relative relocations. IMAGE_REL_BASED_RELPTR32 becomes R_X86_64_PC32/R_AARCH64_PREL32. IMAGE_REL_BASED_REL32 becomes R_X86_64_PLT32. The relevant code that turns REL32 into PLT relocation is here.
  • PLT relocations are not necessary when referencing code within the same section, and they are not optimized away by the compiler. Quite possibly they are not optimized away by the linker either but I didn't check that yet.

@filipnavara
Copy link
Member

vs ~2 bytes on Windows

That's not entirely accurate.

COFF (object) relocation is 10 bytes. PE COFF (image) relocation is page-based, so that's 8 bytes for each page that has relocation and 2 bytes for each relocation within the page. The amortized cost of relocation basically depends on how close you have the pointers within the data structure. The closer they are the bigger chance that they fit within the page and have the 2-byte cost in the final executable.

.rel ELF relocation is 8/16 bytes (32-bit/64-bit). .rela ELF relocation is 12/24 bytes (32-bit/64-bit). They use the same format for object files and image files.

For completeness, Mach-O also compresses the relocations in the final image file. The format is more complex though.

@MichalStrehovsky
Copy link
Member Author

This was fixed in the above mentioned pull requests.

@ghost ghost locked as resolved and limited conversation to collaborators Jul 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-NativeAOT-coreclr help wanted [up-for-grabs] Good issue for external contributors
Projects
Archived in project
Development

No branches or pull requests

2 participants