[cDAC] Implement DacDbi GetNativeCodeInfo / GetNativeCodeInfoForAddr by rcj1 · Pull Request #128338 · dotnet/runtime

rcj1 · 2026-05-18T20:33:25Z

Restructures debugger-side lookup of EnC version data. Previously we had to walk through a hash table of all the DebuggerMethodInfos and then the DebuggerJitInfos to get this data. It was noted that this is quite heavy just to get this one piece of data. We don't have that many EnC versions, so we now have a linked list of these stored on the Module.
Introduces EnC contract to get EnC-related data.

    TargetNUInt GetLatestEnCVersion(TargetPointer module, uint methodDef);
    TargetNUInt GetEnCVersion(TargetPointer module, uint methodDef, TargetCodePointer nativeCodeAddress);

Implements cDAC DacDbi APIs GetNativeCodeInfo and GetNativeCodeInfoForAddr.

note to ccr: do not talk about changing com interface compatibility or compatibility with older datadescriptors.

Co-authored-by: rcj1 <77995559+rcj1@users.noreply.github.com>

dotnet-policy-service · 2026-05-18T20:35:06Z

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

Copilot

Pull request overview

This PR adds cDAC support for DacDbi native-code lookup APIs and introduces a lightweight EnC data contract/list so debugger-side code can retrieve native code region and EnC version information without walking debugger method-info tables.

Changes:

Implements managed cDAC GetNativeCodeInfo / GetNativeCodeInfoForAddr and related interop struct shape.
Adds EnC data descriptors, contract registration, native Module EnC data storage, and DAC lookup changes.
Extends loader/runtime-type-system contracts for member refs and async variant resolution, with design docs.

Show a summary per file

File	Description
`src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/Dbi/IDacDbiInterface.cs`	Updates DacDbi signatures and mirrors native code-info data.
`src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/Dbi/DacDbiImpl.cs`	Implements native-code-info lookup in cDAC.
`src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/EcmaMetadataUtils.cs`	Adds `mdtMemberRef` token type.
`src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/DataType.cs`	Adds `EnCData` descriptor type.
`src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Data/Module.cs`	Reads optional EnC data list from modules.
`src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Data/EnCData.cs`	Adds managed view over native EnC data nodes.
`src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/CoreCLRContracts.cs`	Registers the EnC contract implementation.
`src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/RuntimeTypeSystem_1.cs`	Adds async variant resolution support.
`src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/Loader_1.cs`	Adds member-ref-to-method lookup helper.
`src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/EnC_1.cs`	Implements EnC version lookup contract.
`src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Constants.cs`	Adds default EnC version global name.
`src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Abstractions/Contracts/IRuntimeTypeSystem.cs`	Exposes async variant contract API.
`src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Abstractions/Contracts/ILoader.cs`	Exposes member-ref lookup contract API.
`src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Abstractions/Contracts/IEnC.cs`	Adds public EnC contract abstraction.
`src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Abstractions/ContractRegistry.cs`	Adds EnC contract accessor.
`src/coreclr/vm/datadescriptor/datadescriptor.inc`	Publishes EnC descriptors, global, and contract.
`src/coreclr/vm/ceeload.h`	Adds native EnC data list and lookup helpers to `Module`.
`src/coreclr/debug/inc/dacdbistructures.h`	Widens code-info EnC version field.
`src/coreclr/debug/ee/functioninfo.cpp`	Records EnC data when JIT info is initialized.
`src/coreclr/debug/di/module.cpp`	Casts widened EnC version for DI objects.
`src/coreclr/debug/di/divalue.cpp`	Casts widened EnC version for function lookup.
`src/coreclr/debug/daccess/dacdbiimpl.h`	Updates EnC lookup helper signature.
`src/coreclr/debug/daccess/dacdbiimpl.cpp`	Switches native DAC EnC lookup to new module list.
`docs/design/datacontracts/RuntimeTypeSystem.md`	Documents async variant contract behavior.
`docs/design/datacontracts/Loader.md`	Documents member-ref lookup helper.
`docs/design/datacontracts/EnC.md`	Adds EnC contract design documentation.

Copilot's findings

Files reviewed: 26/26 changed files
Comments generated: 11

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Copilot

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 26/26 changed files
Comments generated: 5

Co-authored-by: rcj1 <77995559+rcj1@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 27/27 changed files
Comments generated: 8

rcj1 · 2026-05-18T22:36:13Z

    this->m_encVersion = this->m_methodInfo->GetCurrentEnCVersion();
+#ifdef FEATURE_METADATA_UPDATER
+    if (this->m_encVersion != CorDB_DEFAULT_ENC_FUNCTION_VERSION)
+    {
+        Module* pModule = this->m_pLoaderModule;
+        EnCData* pEnCData = (EnCData*)(void*)pModule->GetLoaderAllocator()->GetLowFrequencyHeap()->AllocMem(S_SIZE_T(sizeof(EnCData)));
+        pEnCData->addrOfCode = (TADDR)this->m_addrOfCode;
+        pEnCData->token = this->m_methodInfo->m_token;
+        pEnCData->encVersion = this->m_encVersion;
+        pModule->AddEncData(pEnCData);


good catch. Only possibly relevant in

runtime/src/coreclr/debug/di/divalue.cpp

Line 2748 in 3206a8e

HRESULT CordbObjectValue::GetFunction(ICorDebugFunction **ppFunction)

, but could return the latest jitted version as opposed to the latest version total. This is probably worth fixing

+        uint coldSize = 0;
+        if (cbh is not null)
+        {
+            em.GetMethodRegionInfo(cbh.Value, out hotSize, out coldStart, out coldSize);


github-actions · 2026-05-18T22:31:23Z

Caution

Security scanning requires review for Code Review

Details

The threat detection results could not be parsed. The workflow output should be reviewed before merging.

Review the workflow run logs for details.

Note

This review was generated by Copilot.

🤖 Copilot Code Review — PR #128338

Holistic Assessment

Motivation: The PR is well-motivated. It restructures debugger-side EnC version lookup to avoid walking all DebuggerMethodInfo/DebuggerJitInfo entries, introduces a new cDAC EnC contract, and implements the GetNativeCodeInfo/GetNativeCodeInfoForAddr DacDbi APIs in managed code. This is a clear improvement for both performance and cDAC coverage.

Approach: The approach is sound — a simple linked list on Module populated during DebuggerJitInfo::Init provides a lightweight data structure readable by both DAC and cDAC. The contract design follows established patterns. The async variant unwrapping and interpreter precode resolution are correctly handled.

Summary: ⚠️ Needs Human Review. The code is well-structured and follows existing patterns. I have a few concerns around thread safety of AddEncData and the "latest version" semantics that warrant human judgment.

Detailed Findings

⚠️ Thread Safety — `AddEncData` uses non-atomic list prepend

Module::AddEncData does a simple linked-list prepend without any synchronization:

pData->pNext = m_pEnCDataList;
m_pEnCDataList = dac_cast<PTR_EnCData>(pData);

If two threads could EnC-jit methods concurrently on the same module, this is a torn-write race. In practice, EnC likely holds the debugger lock so this may be safe, but it's worth confirming. If it's always called under the debugger lock, a comment to that effect would help future readers. Advisory — not merge-blocking since EnC operations are typically serialized.

⚠️ `GetLatestEnCVersion` returns the first match, not necessarily the latest

FindLatestEncData (native) and FindFirstByToken (cDAC) both return the first entry found by token. Since AddEncData prepends to the list, the first entry is indeed the most recently added one — so this is correct. However, the correctness depends on the prepend-ordering invariant. If the list were ever reordered or if entries were inserted in a different order, this would silently return wrong data. A brief comment in both FindLatestEncData and FindFirstByToken noting "returns most recent because list is prepend-ordered" would improve clarity. Advisory.

✅ Interpreter precode resolution in `GetNativeCodeInfoForAddr`

The review comments show this was caught and fixed — GetInterpreterCodeFromInterpreterPrecodeIfPresent is now called before GetCodeBlockHandle. This correctly mirrors native behavior.

✅ EnC contract is properly optional via `TryGetContract`

Both GetNativeCodeInfo and GetNativeCodeInfoForAddr use TryGetContract<IEnC> so runtimes without FEATURE_METADATA_UPDATER gracefully fall back to the default version. Good pattern.

✅ `NativeCodeFunctionData.encVersion` type change to `ULONG64`

Changing from SIZE_T to ULONG64 makes the wire format consistent across 32/64-bit targets. The casts to (SIZE_T) in the DI layer preserve existing RS behavior. This is correct.

✅ `LookupMemberRefAsMethod` implementation and contract

Clean implementation delegating to existing GetModuleLookupMapElement with the IS_FIELD_MEMBER_REF flag check. Matches the documented contract.

✅ `GetAsyncVariant` implementation

Mirrors the native GetAsyncVariantNoCreate logic correctly — iterates introduced methods on canonical MT, checks matching token with IsAsyncVariant && !ReturnDroppingThunk. This is a read-only lookup that doesn't create anything, matching the "NoCreate" semantics.

💡 `EnC_1` reads `CorDBDefaultEnCFunctionVersion` as `ulong` but stores as `ulong`

The global is declared as T_NUINT in the data descriptor, so on a 32-bit target this would be 4 bytes. ReadGlobal<ulong> reads 8 bytes. This may be fine if ReadGlobal for T_NUINT globals auto-widens, but worth verifying the plumbing handles 32-bit targets correctly. Low confidence — likely fine given existing patterns with other nuint globals.

✅ Debug validation pattern

The #if DEBUG blocks that validate cDAC output against legacy DAC output are thorough and follow the established pattern in other DacDbi implementations. Good for catching regressions during development.

✅ Test coverage

New tests cover both GetNativeCodeInfo (latest EnC version path) and GetNativeCodeInfoForAddr (address-specific EnC version). The mock setup is clean and follows existing test patterns in the file.

Generated by Code Review for issue #128338 · ● 3.6M · ◷

Co-authored-by: rcj1 <77995559+rcj1@users.noreply.github.com>

jkotas · 2026-05-19T03:08:49Z

+    void AddEncData(EnCData* pData)
+    {
+        LIMITED_METHOD_CONTRACT;
+        pData->pNext = m_pEnCDataList;


Does this need synchronization?

jkotas · 2026-05-19T03:10:20Z

+        return nullptr;
+    }
+
+    PTR_EnCData FindLatestEncData(mdMethodDef token)


How does this work with generic methods? Generic methods can have multiple instantiations.

Hm, the thing is this doesn’t look like it ever worked to distinguish generic instantiations when getting the latest EnC version. I wonder if we even need/use this?

Currently I see FindLatestEncData getting used in CordbObjectValue::GetFunctionHelper but it doesn't have to be. Instead of calling CordbModule::LookupOrCreateFunction(token,encVersion) where encVersion ultimately gets calculated in this call you can instead call CordbModule::LookupOrCreateFunctionLatestVersion(token). That LatestVersion variant of the API already has another independent path to discover the latest (potentially unjitted) ENC version based on Debugger::UpdateFunction sending the new ENC version in updates.

Aside from CordbObjectValue::GetFunctionHelper I only see one other callsite for GetNativeCodeInfo and that one doesn't look at the ENC version information that is returned. You could modify GetNativeCodeInfo to only return exactly what that caller needs (MethodDesc+CodeStartAddr) which will eliminate the only callsite that cared about the pLatestEnCVersion param on LookupEnCVersions(). Then you can remove that parameter and this method.

That sounds good. @jkotas it looks like generics in EnC are handled here, in that edits are made per-method and later applied per-instantiation:

runtime/src/coreclr/vm/encee.cpp

Line 376 in 5996b12

// Generics are involved so we need to search for all related MethodDescs.

jkotas · 2026-05-19T03:11:29Z

+        SUPPORTS_DAC;
+        for (PTR_EnCData pCur = m_pEnCDataList; pCur != nullptr; pCur = pCur->pNext)
+        {
+            if (pCur->token == token && pCur->addrOfCode == addrOfCode)


token match should be unnecessary. The code should be enough to identify the method.

jkotas · 2026-05-19T03:14:55Z

+        return nullptr;
+    }
+
+    PTR_EnCData FindLatestEncData(mdMethodDef token)


This will find the most recently JITed method body. It may not be the one with the highest EnC version. My guess is that you expect this is to find the highest EnC version. Is that right?

Yes, copilot pointed this discrepancy out here #128338 (comment). I think I’ll have to bring the mutation of the linked list up next to SetCurrentEnCVersion

We can refactor to remove the dependency on this method entirely (https://github.com/dotnet/runtime/pull/128338/changes#r3265486372)

noahfalk · 2026-05-19T10:14:28Z

+        return nullptr;
+    }
+
+    PTR_EnCData FindLatestEncData(mdMethodDef token)


Currently I see FindLatestEncData getting used in CordbObjectValue::GetFunctionHelper but it doesn't have to be. Instead of calling CordbModule::LookupOrCreateFunction(token,encVersion) where encVersion ultimately gets calculated in this call you can instead call CordbModule::LookupOrCreateFunctionLatestVersion(token). That LatestVersion variant of the API already has another independent path to discover the latest (potentially unjitted) ENC version based on Debugger::UpdateFunction sending the new ENC version in updates.

Aside from CordbObjectValue::GetFunctionHelper I only see one other callsite for GetNativeCodeInfo and that one doesn't look at the ENC version information that is returned. You could modify GetNativeCodeInfo to only return exactly what that caller needs (MethodDesc+CodeStartAddr) which will eliminate the only callsite that cared about the pLatestEnCVersion param on LookupEnCVersions(). Then you can remove that parameter and this method.

noahfalk · 2026-05-19T10:17:04Z

+        return nullptr;
+    }
+
+    PTR_EnCData FindLatestEncData(mdMethodDef token)


We can refactor to remove the dependency on this method entirely (https://github.com/dotnet/runtime/pull/128338/changes#r3265486372)

noahfalk · 2026-05-19T11:11:57Z

+    {
+        LIMITED_METHOD_CONTRACT;
+        SUPPORTS_DAC;
+        for (PTR_EnCData pCur = m_pEnCDataList; pCur != nullptr; pCur = pCur->pNext)


I'm worried about the performance overhead of an O(N) linked list search. Although I suspect many uses of ENC are small I'm not confident that all of them are and this method can get called a lot.

Rather than a new linked list, how about we add the ENC version to the method DebugInfo? We could add an ENCVersion as the 7th item in the FAT header. This would have no cost for most methods which use the slim header or 1 nibble per method for those using the FAT header.

If we don't have to keep track of unjitted methods, we could stuff the EnC version into the code header.

I do not think it belongs to code header directly.

I think having in the side-table where it is today or in the debug info as suggested by Noah are reasonable options.

We do have yet another code version scheme for tiered compilation and Rejit. Rejit is very much like EnC. Would it make sense to store the EnC version in the existing structure used by tiered compilation and Rejit? (ILCodeVersionNode, NativeCodeVersionNode, etc.)

Would it make sense to store the EnC version in the existing structure used by tiered compilation and Rejit?

Architecturally yes, it makes sense to have it there. I didn't initially propose that because I worried it might be a more elaborate change, but its where I envisioned ENC would be some day. If it winds up being not too hard to add it there right now thats very nice. I am guessing some of the work along that route would be:

ENC currently uses independent logic to determine the active version and switch between versions

ICorDebug is aware of ILCodeVersions but currently they have different treatment than ENC versions. Right now ILCodeVersions generate multiple ICorDebugILCode objects parented under the same ICorDebugFunction whereas ENC expects multiple unique ICorDebugFunctions. Assuming new ENCVersions get represented at runtime as new ILCodeVersionNodes we'd need to teach ICorDebug to distinguish them.

If we are just concerned about performance, a cheap alternative would be to add a lookup map keyed by method token on the module, and have it store a pointer to per-token linked lists of (codeAddr, version) - the same structure used in ILCodeVersions. I am not sure how much work it would be to completely unify EnC and ReJIT, or if maybe there is a middle ground where we add a node but say "actually this is an EnC version".

if maybe there is a middle ground where we add a node but say "actually this is an EnC version".

I think it would be a significant improvement compared to what we have today.

if maybe there is a middle ground where we add a node but say "actually this is an EnC version".

I think it would be a significant improvement compared to what we have today.

I can see us introducing ILCodeVersions for each EnC edit, each of which would get a singular NativeCodeVersion. We would not fold the actual logic of EnC into the logic for CodeVersions, which means that the existing iterators over CodeVersions would have to be updated to skip EnC nodes. We could even fold the APIs I just added on the EnC contract into the CodeVersions contract; it would be iterating the same data with a different filter.

Do you think this makes sense or would we have to go further in integrating the two for it to make sense?

I don't believe finding EnC methods, fields, etc would be easily folded into CodeVersions. So we would still need an EnC contract until this goes away.

[cDAC] Implement DacDbi GetNativeCodeInfo / GetNativeCodeInfoForAddr

352ebcc

Co-authored-by: rcj1 <77995559+rcj1@users.noreply.github.com>

rcj1 requested review from Copilot, davidwrighton, jkotas, noahfalk and tommcdon May 18, 2026 20:33

github-actions Bot added the area-Diagnostics-coreclr label May 18, 2026

rcj1 added area-Diagnostics-cdac and removed area-Diagnostics-coreclr labels May 18, 2026

dotnet-policy-service Bot assigned rcj1 May 18, 2026

Update IDacDbiInterface.cs

794e87e

This comment has been minimized.

Sign in to view

Copilot AI reviewed May 18, 2026

View reviewed changes

Copilot started reviewing on behalf of rcj1 May 18, 2026 20:44 View session

Apply suggestions from code review

1a185ec

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Copilot AI review requested due to automatic review settings May 18, 2026 20:47

Copilot AI reviewed May 18, 2026

View reviewed changes

Potential fix for pull request finding

51fe617

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Copilot AI review requested due to automatic review settings May 18, 2026 20:50

Copilot started reviewing on behalf of rcj1 May 18, 2026 20:50 View session

This comment has been minimized.

Sign in to view

Copilot AI reviewed May 18, 2026

View reviewed changes

Copilot started work on behalf of rcj1 May 18, 2026 21:01 View session

ccr

109f48f

This comment has been minimized.

Sign in to view

Add EnC unit tests for cDAC DacDbi native code APIs

efc62f0

Co-authored-by: rcj1 <77995559+rcj1@users.noreply.github.com>

Copilot AI review requested due to automatic review settings May 18, 2026 21:11

rcj1 review requested due to automatic review settings May 18, 2026 21:11

Copilot finished work on behalf of rcj1 May 18, 2026 21:12

Copilot AI reviewed May 18, 2026

View reviewed changes

fix buidl break

7f0ded6

rcj1 force-pushed the copilot/cdac-enc-getnativecodeinfo branch from 829f44a to 7f0ded6 Compare May 18, 2026 22:24

Copilot started work on behalf of rcj1 May 18, 2026 22:27 View session

Add EnC contract unit tests

a948fbc

Co-authored-by: rcj1 <77995559+rcj1@users.noreply.github.com>

Copilot AI review requested due to automatic review settings May 18, 2026 22:33

rcj1 review requested due to automatic review settings May 18, 2026 22:33

Refine EnC contract test names

5d7dd6f

Co-authored-by: rcj1 <77995559+rcj1@users.noreply.github.com>

Copilot AI review requested due to automatic review settings May 18, 2026 22:34

rcj1 review requested due to automatic review settings May 18, 2026 22:34

Polish EnC contract unit test scaffolding

dfaa609

Co-authored-by: rcj1 <77995559+rcj1@users.noreply.github.com>

Copilot AI review requested due to automatic review settings May 18, 2026 22:35

rcj1 review requested due to automatic review settings May 18, 2026 22:35

Rename EnC contract tests for clarity

575085a

Co-authored-by: rcj1 <77995559+rcj1@users.noreply.github.com>

Copilot AI review requested due to automatic review settings May 18, 2026 22:35

rcj1 review requested due to automatic review settings May 18, 2026 22:35

Tidy EnC unit test naming

e7644f1

Co-authored-by: rcj1 <77995559+rcj1@users.noreply.github.com>

Copilot AI review requested due to automatic review settings May 18, 2026 22:36

rcj1 review requested due to automatic review settings May 18, 2026 22:36

Clarify EnC unit test locals

2b2c1a8

Co-authored-by: rcj1 <77995559+rcj1@users.noreply.github.com>

Copilot AI review requested due to automatic review settings May 18, 2026 22:37

rcj1 review requested due to automatic review settings May 18, 2026 22:37

Copilot finished work on behalf of rcj1 May 18, 2026 22:38

jkotas reviewed May 19, 2026

View reviewed changes

noahfalk reviewed May 19, 2026

View reviewed changes

Conversation

rcj1 commented May 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-service Bot commented May 18, 2026

Uh oh!

This comment has been minimized.

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Copilot's findings

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

Copilot AI left a comment

Choose a reason for hiding this comment

Copilot's findings

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

Copilot AI left a comment

Choose a reason for hiding this comment

Copilot's findings

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rcj1 May 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented May 18, 2026

🤖 Copilot Code Review — PR #128338

Holistic Assessment

Detailed Findings

⚠️ Thread Safety — AddEncData uses non-atomic list prepend

⚠️ GetLatestEnCVersion returns the first match, not necessarily the latest

✅ Interpreter precode resolution in GetNativeCodeInfoForAddr

✅ EnC contract is properly optional via TryGetContract

✅ NativeCodeFunctionData.encVersion type change to ULONG64

✅ LookupMemberRefAsMethod implementation and contract

✅ GetAsyncVariant implementation

💡 EnC_1 reads CorDBDefaultEnCFunctionVersion as ulong but stores as ulong

✅ Debug validation pattern

✅ Test coverage

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

rcj1 commented May 18, 2026 •

edited

Loading

rcj1 May 18, 2026 •

edited

Loading

⚠️ Thread Safety — `AddEncData` uses non-atomic list prepend

⚠️ `GetLatestEnCVersion` returns the first match, not necessarily the latest

✅ Interpreter precode resolution in `GetNativeCodeInfoForAddr`

✅ EnC contract is properly optional via `TryGetContract`

✅ `NativeCodeFunctionData.encVersion` type change to `ULONG64`

✅ `LookupMemberRefAsMethod` implementation and contract

✅ `GetAsyncVariant` implementation

💡 `EnC_1` reads `CorDBDefaultEnCFunctionVersion` as `ulong` but stores as `ulong`

rcj1 May 19, 2026 •

edited

Loading

rcj1 May 19, 2026 •

edited

Loading