-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Improving and unifying handling of native Libraries code in embedded/singlefile scenarios #41299
Comments
Dotnet-GitSync-Bot
added
the
untriaged
New issue has not been triaged by the area owner
label
Aug 24, 2020
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Assigning to .NET 6 milestone as this is a design proposal, not a bug fix, and I believe it's too late in the .NET 5 release cycle to introduce new feature work. |
This was referenced Oct 21, 2020
This was implemented in #44505 |
ghost
locked as resolved and limited conversation to collaborators
Jan 17, 2021
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Improving handling of native Libraries code in embedded/singlefile scenarios
For reasons that vary .Net libraries rely on nontrivial amount of native code. The native code is factored into a few well-known native dynamic-link libraries (.dll, .so, etc). As an example we have 4 libraries like this on Linux – "libSystem.Native", "libSystem.IO.Compression.Native", "libSystem.Net.Security.Native", "libSystem.Security.Cryptography.Native.OpenSsl". The number of libraries varies depending on platform.
This is a very simple model which has its own advantages. In particular there is no need for coreclr to have any special knowledge about these libraries.
Where this becomes inconvenient and fragile is when we want to package the native libraries differently - for example as a part of a single file host. To handle such requirement in the current implementation we produce static libraries for the native code and link that into coreclr/host. Since the native dlls are not longer around in this configuration, coreclr intercepts loading of these libraries and redirects to the containing host binary.
There is a number of issues:
Proposal:
Build native libraries as a part of CoreClr build.
The source files should still be located under Libraries partition, so that they can be shared in source form with Mono, for example.
The “embedded” case builds native libraries as a part of coreclr binary, thus bypassing the explicit lib files.
The "embedded" case recognizes well-known libraries as a special case of QCall and dispatches calls to the embedded implementations.
Example: “libSystem.Native” would normally be a name of the native library to load, but in “embedded” case, the DLLEXPORT methods of libSystem.Native would be registered in the runtime similarly to QCall and “libSystem.Native” would be recognized as another QCall variety.
QCall mechanism here allows us to “shim” the location of native methods while not changing the managed code that calls them.
The QCall registration table for the native calls will be automatically generated by scanning managed libraries.
Some unresolved details:
The text was updated successfully, but these errors were encountered: