You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
3. On Unix platforms that are not Apple derived we use an anonymous in memory file just like our normal executable allocation path.
3. 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.
4. On Windows platforms, we currently do not yet support this mode.
// If templateInImage is not null, it will attempt to use it as the template, otherwise it will create an temporary in memory file to serve as the template
277
+
// Some OS/Architectures may/may not be able to work with this, so this api is permitted to return NULL, and callers should have an alternate approach using
0 commit comments