[cDAC] Restore non-stub method resolution in GetRuntimeNameByAddress

[rcj1]

#127134 removed handling of non-stubs, however, there are still tools that need this functionality.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

Restores the ability for DAC/cDAC consumers to resolve managed method names (not just stub names) from an address, including cases where the address is an interpreter precode / entrypoint that must be mapped to the underlying managed code before symbolizing.

Changes:

• cDAC legacy IXCLRDataProcess.GetRuntimeNameByAddress now first attempts to resolve a CodeBlockHandle (after mapping interpreter precodes) and formats a real method name when available.
• CoreCLR DAC ClrDataAccess::RawGetMethodName now attempts EECodeInfo after mapping interpreter entrypoints, returning the full managed method name early when possible.

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs	Adds a non-stub method-resolution fast path via PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent + ExecutionManager.GetCodeBlockHandle, and factors method name formatting into a helper.
src/coreclr/debug/daccess/daccess.cpp	Adds an early EECodeInfo-based managed method name resolution path (after interpreter entrypoint mapping) before falling back to stub manager classification.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 3

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Copilot's findings

Suppressed comments (2)

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs:255

• This restores method-name resolution for non-stub addresses, but there are no unit tests covering the new behavior (including the displacement value) for (1) normal managed code addresses and (2) interpreter precode mapping. There is an existing test suite for IXCLRDataProcess in src/native/managed/cdac/tests/UnitTests/IXCLRDataProcessTests.cs that looks like the right place to add coverage.

[!NOTE] This comment was created by GitHub Copilot.

 TargetCodePointer managedCodeAddr = _target.Contracts.PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent(codeAddr);
if (eman.GetCodeBlockHandle(managedCodeAddr) is CodeBlockHandle codeBlock)
{

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs:259

• Displacement for the non-stub path is computed as a raw address delta (managedCodeAddr - GetStartAddress). That can be incorrect for ReadyToRun hot/cold-split methods: the logical code offset is not the same as the gap in address space. ExecutionManager already computes the correct relative offset (including hot/cold adjustments) in IExecutionManager.GetRelativeOffset(codeBlock), so use that instead.

[!NOTE] This comment was created by GitHub Copilot.

 if (displacement is not null)
{
*displacement = managedCodeAddr.ToAddress(_target).Value - eman.GetStartAddress(codeBlock).Value;
}

• Files reviewed: 2/2 changed files
• Comments generated: 0 new

[rcj1]

/ba-g somehow we failed to collect dumps on a test.

[rcj1]

#127134 removed handling of non-stubs, however, there are still tools that need this functionality.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

Restores the ability for DAC/cDAC consumers to resolve managed method names (not just stub names) from an address, including cases where the address is an interpreter precode / entrypoint that must be mapped to the underlying managed code before symbolizing.

Changes:

• cDAC legacy IXCLRDataProcess.GetRuntimeNameByAddress now first attempts to resolve a CodeBlockHandle (after mapping interpreter precodes) and formats a real method name when available.
• CoreCLR DAC ClrDataAccess::RawGetMethodName now attempts EECodeInfo after mapping interpreter entrypoints, returning the full managed method name early when possible.

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs	Adds a non-stub method-resolution fast path via PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent + ExecutionManager.GetCodeBlockHandle, and factors method name formatting into a helper.
src/coreclr/debug/daccess/daccess.cpp	Adds an early EECodeInfo-based managed method name resolution path (after interpreter entrypoint mapping) before falling back to stub manager classification.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 3

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Copilot's findings

Suppressed comments (2)

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs:255

• This restores method-name resolution for non-stub addresses, but there are no unit tests covering the new behavior (including the displacement value) for (1) normal managed code addresses and (2) interpreter precode mapping. There is an existing test suite for IXCLRDataProcess in src/native/managed/cdac/tests/UnitTests/IXCLRDataProcessTests.cs that looks like the right place to add coverage.

[!NOTE] This comment was created by GitHub Copilot.

 TargetCodePointer managedCodeAddr = _target.Contracts.PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent(codeAddr);
if (eman.GetCodeBlockHandle(managedCodeAddr) is CodeBlockHandle codeBlock)
{

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs:259

• Displacement for the non-stub path is computed as a raw address delta (managedCodeAddr - GetStartAddress). That can be incorrect for ReadyToRun hot/cold-split methods: the logical code offset is not the same as the gap in address space. ExecutionManager already computes the correct relative offset (including hot/cold adjustments) in IExecutionManager.GetRelativeOffset(codeBlock), so use that instead.

[!NOTE] This comment was created by GitHub Copilot.

 if (displacement is not null)
{
*displacement = managedCodeAddr.ToAddress(_target).Value - eman.GetStartAddress(codeBlock).Value;
}

• Files reviewed: 2/2 changed files
• Comments generated: 0 new

[rcj1]

/ba-g somehow we failed to collect dumps on a test.

[rcj1]

#127134 removed handling of non-stubs, however, there are still tools that need this functionality.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

Restores the ability for DAC/cDAC consumers to resolve managed method names (not just stub names) from an address, including cases where the address is an interpreter precode / entrypoint that must be mapped to the underlying managed code before symbolizing.

Changes:

• cDAC legacy IXCLRDataProcess.GetRuntimeNameByAddress now first attempts to resolve a CodeBlockHandle (after mapping interpreter precodes) and formats a real method name when available.
• CoreCLR DAC ClrDataAccess::RawGetMethodName now attempts EECodeInfo after mapping interpreter entrypoints, returning the full managed method name early when possible.

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs	Adds a non-stub method-resolution fast path via PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent + ExecutionManager.GetCodeBlockHandle, and factors method name formatting into a helper.
src/coreclr/debug/daccess/daccess.cpp	Adds an early EECodeInfo-based managed method name resolution path (after interpreter entrypoint mapping) before falling back to stub manager classification.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 3

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Copilot's findings

Suppressed comments (2)

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs:255

• This restores method-name resolution for non-stub addresses, but there are no unit tests covering the new behavior (including the displacement value) for (1) normal managed code addresses and (2) interpreter precode mapping. There is an existing test suite for IXCLRDataProcess in src/native/managed/cdac/tests/UnitTests/IXCLRDataProcessTests.cs that looks like the right place to add coverage.

[!NOTE] This comment was created by GitHub Copilot.

 TargetCodePointer managedCodeAddr = _target.Contracts.PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent(codeAddr);
if (eman.GetCodeBlockHandle(managedCodeAddr) is CodeBlockHandle codeBlock)
{

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs:259

• Displacement for the non-stub path is computed as a raw address delta (managedCodeAddr - GetStartAddress). That can be incorrect for ReadyToRun hot/cold-split methods: the logical code offset is not the same as the gap in address space. ExecutionManager already computes the correct relative offset (including hot/cold adjustments) in IExecutionManager.GetRelativeOffset(codeBlock), so use that instead.

[!NOTE] This comment was created by GitHub Copilot.

 if (displacement is not null)
{
*displacement = managedCodeAddr.ToAddress(_target).Value - eman.GetStartAddress(codeBlock).Value;
}

• Files reviewed: 2/2 changed files
• Comments generated: 0 new

[rcj1]

/ba-g somehow we failed to collect dumps on a test.

[rcj1]

#127134 removed handling of non-stubs, however, there are still tools that need this functionality.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

Restores the ability for DAC/cDAC consumers to resolve managed method names (not just stub names) from an address, including cases where the address is an interpreter precode / entrypoint that must be mapped to the underlying managed code before symbolizing.

Changes:

• cDAC legacy IXCLRDataProcess.GetRuntimeNameByAddress now first attempts to resolve a CodeBlockHandle (after mapping interpreter precodes) and formats a real method name when available.
• CoreCLR DAC ClrDataAccess::RawGetMethodName now attempts EECodeInfo after mapping interpreter entrypoints, returning the full managed method name early when possible.

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs	Adds a non-stub method-resolution fast path via PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent + ExecutionManager.GetCodeBlockHandle, and factors method name formatting into a helper.
src/coreclr/debug/daccess/daccess.cpp	Adds an early EECodeInfo-based managed method name resolution path (after interpreter entrypoint mapping) before falling back to stub manager classification.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 3

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Copilot's findings

Suppressed comments (2)

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs:255

• This restores method-name resolution for non-stub addresses, but there are no unit tests covering the new behavior (including the displacement value) for (1) normal managed code addresses and (2) interpreter precode mapping. There is an existing test suite for IXCLRDataProcess in src/native/managed/cdac/tests/UnitTests/IXCLRDataProcessTests.cs that looks like the right place to add coverage.

[!NOTE] This comment was created by GitHub Copilot.

 TargetCodePointer managedCodeAddr = _target.Contracts.PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent(codeAddr);
if (eman.GetCodeBlockHandle(managedCodeAddr) is CodeBlockHandle codeBlock)
{

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs:259

• Displacement for the non-stub path is computed as a raw address delta (managedCodeAddr - GetStartAddress). That can be incorrect for ReadyToRun hot/cold-split methods: the logical code offset is not the same as the gap in address space. ExecutionManager already computes the correct relative offset (including hot/cold adjustments) in IExecutionManager.GetRelativeOffset(codeBlock), so use that instead.

[!NOTE] This comment was created by GitHub Copilot.

 if (displacement is not null)
{
*displacement = managedCodeAddr.ToAddress(_target).Value - eman.GetStartAddress(codeBlock).Value;
}

• Files reviewed: 2/2 changed files
• Comments generated: 0 new

[rcj1]

/ba-g somehow we failed to collect dumps on a test.

[rcj1]

#127134 removed handling of non-stubs, however, there are still tools that need this functionality.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

Restores the ability for DAC/cDAC consumers to resolve managed method names (not just stub names) from an address, including cases where the address is an interpreter precode / entrypoint that must be mapped to the underlying managed code before symbolizing.

Changes:

• cDAC legacy IXCLRDataProcess.GetRuntimeNameByAddress now first attempts to resolve a CodeBlockHandle (after mapping interpreter precodes) and formats a real method name when available.
• CoreCLR DAC ClrDataAccess::RawGetMethodName now attempts EECodeInfo after mapping interpreter entrypoints, returning the full managed method name early when possible.

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs	Adds a non-stub method-resolution fast path via PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent + ExecutionManager.GetCodeBlockHandle, and factors method name formatting into a helper.
src/coreclr/debug/daccess/daccess.cpp	Adds an early EECodeInfo-based managed method name resolution path (after interpreter entrypoint mapping) before falling back to stub manager classification.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 3

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Copilot's findings

Suppressed comments (2)

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs:255

• This restores method-name resolution for non-stub addresses, but there are no unit tests covering the new behavior (including the displacement value) for (1) normal managed code addresses and (2) interpreter precode mapping. There is an existing test suite for IXCLRDataProcess in src/native/managed/cdac/tests/UnitTests/IXCLRDataProcessTests.cs that looks like the right place to add coverage.

[!NOTE] This comment was created by GitHub Copilot.

 TargetCodePointer managedCodeAddr = _target.Contracts.PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent(codeAddr);
if (eman.GetCodeBlockHandle(managedCodeAddr) is CodeBlockHandle codeBlock)
{

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs:259

• Displacement for the non-stub path is computed as a raw address delta (managedCodeAddr - GetStartAddress). That can be incorrect for ReadyToRun hot/cold-split methods: the logical code offset is not the same as the gap in address space. ExecutionManager already computes the correct relative offset (including hot/cold adjustments) in IExecutionManager.GetRelativeOffset(codeBlock), so use that instead.

[!NOTE] This comment was created by GitHub Copilot.

 if (displacement is not null)
{
*displacement = managedCodeAddr.ToAddress(_target).Value - eman.GetStartAddress(codeBlock).Value;
}

• Files reviewed: 2/2 changed files
• Comments generated: 0 new

[rcj1]

/ba-g somehow we failed to collect dumps on a test.

[rcj1]

#127134 removed handling of non-stubs, however, there are still tools that need this functionality.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

Restores the ability for DAC/cDAC consumers to resolve managed method names (not just stub names) from an address, including cases where the address is an interpreter precode / entrypoint that must be mapped to the underlying managed code before symbolizing.

Changes:

• cDAC legacy IXCLRDataProcess.GetRuntimeNameByAddress now first attempts to resolve a CodeBlockHandle (after mapping interpreter precodes) and formats a real method name when available.
• CoreCLR DAC ClrDataAccess::RawGetMethodName now attempts EECodeInfo after mapping interpreter entrypoints, returning the full managed method name early when possible.

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs	Adds a non-stub method-resolution fast path via PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent + ExecutionManager.GetCodeBlockHandle, and factors method name formatting into a helper.
src/coreclr/debug/daccess/daccess.cpp	Adds an early EECodeInfo-based managed method name resolution path (after interpreter entrypoint mapping) before falling back to stub manager classification.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 3

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Copilot's findings

Suppressed comments (2)

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs:255

• This restores method-name resolution for non-stub addresses, but there are no unit tests covering the new behavior (including the displacement value) for (1) normal managed code addresses and (2) interpreter precode mapping. There is an existing test suite for IXCLRDataProcess in src/native/managed/cdac/tests/UnitTests/IXCLRDataProcessTests.cs that looks like the right place to add coverage.

[!NOTE] This comment was created by GitHub Copilot.

 TargetCodePointer managedCodeAddr = _target.Contracts.PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent(codeAddr);
if (eman.GetCodeBlockHandle(managedCodeAddr) is CodeBlockHandle codeBlock)
{

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs:259

• Displacement for the non-stub path is computed as a raw address delta (managedCodeAddr - GetStartAddress). That can be incorrect for ReadyToRun hot/cold-split methods: the logical code offset is not the same as the gap in address space. ExecutionManager already computes the correct relative offset (including hot/cold adjustments) in IExecutionManager.GetRelativeOffset(codeBlock), so use that instead.

[!NOTE] This comment was created by GitHub Copilot.

 if (displacement is not null)
{
*displacement = managedCodeAddr.ToAddress(_target).Value - eman.GetStartAddress(codeBlock).Value;
}

• Files reviewed: 2/2 changed files
• Comments generated: 0 new

[rcj1]

/ba-g somehow we failed to collect dumps on a test.

[rcj1]

#127134 removed handling of non-stubs, however, there are still tools that need this functionality.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

Restores the ability for DAC/cDAC consumers to resolve managed method names (not just stub names) from an address, including cases where the address is an interpreter precode / entrypoint that must be mapped to the underlying managed code before symbolizing.

Changes:

• cDAC legacy IXCLRDataProcess.GetRuntimeNameByAddress now first attempts to resolve a CodeBlockHandle (after mapping interpreter precodes) and formats a real method name when available.
• CoreCLR DAC ClrDataAccess::RawGetMethodName now attempts EECodeInfo after mapping interpreter entrypoints, returning the full managed method name early when possible.

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs	Adds a non-stub method-resolution fast path via PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent + ExecutionManager.GetCodeBlockHandle, and factors method name formatting into a helper.
src/coreclr/debug/daccess/daccess.cpp	Adds an early EECodeInfo-based managed method name resolution path (after interpreter entrypoint mapping) before falling back to stub manager classification.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 3

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Copilot's findings

Suppressed comments (2)

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs:255

• This restores method-name resolution for non-stub addresses, but there are no unit tests covering the new behavior (including the displacement value) for (1) normal managed code addresses and (2) interpreter precode mapping. There is an existing test suite for IXCLRDataProcess in src/native/managed/cdac/tests/UnitTests/IXCLRDataProcessTests.cs that looks like the right place to add coverage.

[!NOTE] This comment was created by GitHub Copilot.

 TargetCodePointer managedCodeAddr = _target.Contracts.PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent(codeAddr);
if (eman.GetCodeBlockHandle(managedCodeAddr) is CodeBlockHandle codeBlock)
{

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs:259

• Displacement for the non-stub path is computed as a raw address delta (managedCodeAddr - GetStartAddress). That can be incorrect for ReadyToRun hot/cold-split methods: the logical code offset is not the same as the gap in address space. ExecutionManager already computes the correct relative offset (including hot/cold adjustments) in IExecutionManager.GetRelativeOffset(codeBlock), so use that instead.

[!NOTE] This comment was created by GitHub Copilot.

 if (displacement is not null)
{
*displacement = managedCodeAddr.ToAddress(_target).Value - eman.GetStartAddress(codeBlock).Value;
}

• Files reviewed: 2/2 changed files
• Comments generated: 0 new

[rcj1]

/ba-g somehow we failed to collect dumps on a test.

[rcj1]

#127134 removed handling of non-stubs, however, there are still tools that need this functionality.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

Restores the ability for DAC/cDAC consumers to resolve managed method names (not just stub names) from an address, including cases where the address is an interpreter precode / entrypoint that must be mapped to the underlying managed code before symbolizing.

Changes:

• cDAC legacy IXCLRDataProcess.GetRuntimeNameByAddress now first attempts to resolve a CodeBlockHandle (after mapping interpreter precodes) and formats a real method name when available.
• CoreCLR DAC ClrDataAccess::RawGetMethodName now attempts EECodeInfo after mapping interpreter entrypoints, returning the full managed method name early when possible.

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs	Adds a non-stub method-resolution fast path via PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent + ExecutionManager.GetCodeBlockHandle, and factors method name formatting into a helper.
src/coreclr/debug/daccess/daccess.cpp	Adds an early EECodeInfo-based managed method name resolution path (after interpreter entrypoint mapping) before falling back to stub manager classification.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 3

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Copilot's findings

Suppressed comments (2)

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs:255

• This restores method-name resolution for non-stub addresses, but there are no unit tests covering the new behavior (including the displacement value) for (1) normal managed code addresses and (2) interpreter precode mapping. There is an existing test suite for IXCLRDataProcess in src/native/managed/cdac/tests/UnitTests/IXCLRDataProcessTests.cs that looks like the right place to add coverage.

[!NOTE] This comment was created by GitHub Copilot.

 TargetCodePointer managedCodeAddr = _target.Contracts.PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent(codeAddr);
if (eman.GetCodeBlockHandle(managedCodeAddr) is CodeBlockHandle codeBlock)
{

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.IXCLRDataProcess.cs:259

• Displacement for the non-stub path is computed as a raw address delta (managedCodeAddr - GetStartAddress). That can be incorrect for ReadyToRun hot/cold-split methods: the logical code offset is not the same as the gap in address space. ExecutionManager already computes the correct relative offset (including hot/cold adjustments) in IExecutionManager.GetRelativeOffset(codeBlock), so use that instead.

[!NOTE] This comment was created by GitHub Copilot.

 if (displacement is not null)
{
*displacement = managedCodeAddr.ToAddress(_target).Value - eman.GetStartAddress(codeBlock).Value;
}

• Files reviewed: 2/2 changed files
• Comments generated: 0 new

[rcj1]

/ba-g somehow we failed to collect dumps on a test.