-
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
Add DNMD into src/native #107961
base: main
Are you sure you want to change the base?
Add DNMD into src/native #107961
Conversation
Includes basic structure, readme.md and Cmake for building.
Update CoTaskMemAlloc to 8-byte align.
Add base COM interfaces
Update C++ #ifdef Add == operator for GUIDs
Updates GUID and BSTR tests.
Scenario tests broken on Windows.
uppercase hexidecmal strings for GUIDs.
Move util.h out of public inc/ dir Add test for InvalidCastException Fix memory leak in scenario test
Add dncp::com_ptr smart pointer for IUnknown
Add common wide string APIs
Create dotnet based project system for ease of use. Create MSBuild system that works with the basic dotnet commands. Add notes to readme on how to test using the dotnet SDK.
…o our compiler discovery routines.
…ry changes to get tests running locally again.
… that case and our host systems don't have what we'd need
… dnmd-in-runtime # Conflicts: # src/native/minipal/CMakeLists.txt
Is it actually going to be a net win to use unmanaged metadata reader in cDAC? |
It would make more sense to me to focus on this part: prove that this metadata reader is at least as good as the existing runtime reader and replace the current the runtime reader. |
void (*func)(const uint8_t*, size_t, uint8_t*); | ||
sha1_func() | ||
{ | ||
void* img_handle = dlopen("libcrypto.so", RTLD_LAZY); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not think we want to introduce a core runtime dependency on OpenSSL. OpenSSL (and other real crypto stacks) can be locked down in various ways. We do not want to the core runtime to fail to start if they decide to lock down the legacy hash alg. It creates a whole new set of failure modes.
The core runtime has an exception for non-crypto use of the legacy crypto hash algorithms. If we wanted to do something about it, we would take a breaking change to switch to non-crypto hash algorithms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll move the SHA1 implementation from CoreCLR into the minipal and use it from here (for the exact same case that it's used in CoreCLR today).
For cDAC in particular, the idea was to use DNMD for the IMetaDataImport exposure from CLRDataModule.
I'd like to eventually use DNMD throughout the repo, but I plan to do more perf work in actual CoreCLR and Mono scenarios (after merging this preferably as doing actual testing in the runtime will require some corresponding runtime changes). |
Is IMetaDataImport interface exposed by this? I only see several custom enumerators. Also, we have discussed the possibility of cDac world no longer supporting some of the redundant DAC interfaces like IXCLRData... that are only used by windbg for historic reasons and where fixing windbg may be a better long-term path. |
It is through a "poor-man's COM Aggregation" implementation in the QueryInterface implementation. @davidwrighton asked about using DNMD for this case (which is why I looked at doing this for the hackathon now). |
Add dnmd into the dotnet/runtime repo for usage by cDAC (and in the future, usage as the native ECMA-335 metadata library for the repo as a whole).
Depends on #107889