Skip to content

Create a single copy of stub templates #114462

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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

davidwrighton
Copy link
Member

@davidwrighton davidwrighton commented Apr 9, 2025

Instead of generating stub templates by running the code page generation function for each stub code region that is generated, map a single file into memory in multiple locations instead. This logic is architected so that it can fall back to the previous model of using the double mapping logic to generate the stubs.

We implement 3 schemes for finding the to use as mapping data.

  1. On apple platforms, we compile the stubs into the coreclr Mach-O file, and use the virtual memory manager support for mapping memory from the coreclr binary into various locations on the heap.
  2. On Linux platforms, we can compile the stubs into the coreclr ELF file, and then use the dladdr and dl_iterate_phdr functionality to find the file name of the coreclr binary and the section that contains it, and then we can use mmap to map from the file directly into memory. This mode is disabled by default as it doesn't support all scenarios, but it does allow for testing of the majority of the logic used on Apple platforms on a Linux machine.
  3. On Unix platforms that are not Linux or Linux when mode 2 is not enabled, we use an anonymous in memory file just like our normal executable allocation path.
  4. On Windows platforms, we currently do not yet support this mode.

Copy link
Contributor

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

@am11
Copy link
Member

am11 commented Apr 10, 2025

3. On Unix platforms that are not Linux,

We can classify them based on binary format main...am11:runtime:binfmt and use: #ifdef MINIPAL_TARGET_ELF to treat all ELF platforms alike.

commit 40f2a6ac4c7393294d794f55aa9206f8eb815b5c
Author: David Wrighton <[email protected]>
Date:   Tue Apr 1 15:16:13 2025 -0700

    Build out ExecutableAllocator api for template mapping

commit dd22e4213563461948e702f035c0558784c3f767
Author: David Wrighton <[email protected]>
Date:   Tue Apr 1 13:07:42 2025 -0700

    X64 template code gen is correct

commit 89fb8b6
Author: David Wrighton <[email protected]>
Date:   Mon Mar 31 14:00:23 2025 -0700

    Add support for Amd64 thunk pages
@davidwrighton davidwrighton marked this pull request as ready for review April 16, 2025 17:26
@Copilot Copilot AI review requested due to automatic review settings April 16, 2025 17:26
@davidwrighton davidwrighton changed the title [DRAFT] Create a single copy of stub templates Create a single copy of stub templates Apr 16, 2025
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot reviewed 12 out of 15 changed files in this pull request and generated no comments.

Files not reviewed (3)
  • src/coreclr/clrdefinitions.cmake: Language not supported
  • src/coreclr/vm/amd64/thunktemplates.S: Language not supported
  • src/coreclr/vm/arm64/thunktemplates.S: Language not supported
Comments suppressed due to low confidence (2)

src/coreclr/vm/precode.cpp:527

  • [nitpick] Consider replacing the magic constant 0x4000 with a named constant (e.g. kExpectedTemplatePageSize) to improve code clarity and maintainability.
if (StubPrecodeCodeTemplate != NULL && pageSize != 0x4000)

src/coreclr/vm/precode.cpp:674

  • [nitpick] Consider replacing the magic constant 0x4000 with a named constant to enhance clarity and maintainability in the template usage check.
if (FixupPrecodeCodeTemplate != NULL && pageSize != 0x4000)

Copy link
Member

@filipnavara filipnavara left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW I checked the Apple specific code paths and they look reasonable.

I skimmed over the Linux parts too; they are similar in principle to the code used in NativeAOT before the switch to vm_remap. I didn't review them in detail though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants