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
* Disassembly follow jump trampolines.
* Revert ProcessExtensions.
* Fix DisassemblyDiagnoser for indirect calls through precodes
Replace byte-for-byte stub precode template matching with opcode-based
pattern matching that extracts RIP-relative displacements directly from
the encoded instructions, so the resolver survives StubPrecodeData
layout shifts between .NET runtime patch versions.
For StubPrecode and FixupPrecode, resolve to the MethodDesc slot rather
than the Target slot, since Target may still point at PreStub or
PrecodeFixupThunk when the call site has never been backpatched
(common with CallCountingDelayMs=0). The MethodDesc handle lets
GetMethodByHandle recover the live ClrMethod regardless of backpatch
state. When the handle resolves, also enqueue the method for
disassembly rather than only labeling it "Precode of X".
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* Address PR feedback: opcode-based stub matching everywhere
- Reword the rationale comment: the data-section layout is stable; what
varies between runtime versions is the offset between the code page
and its data section (the stub page size). Extracting RIP-relative
displacements from the encoded instructions themselves is what makes
the resolver independent of that gap.
- Apply the same opcode-based approach to TryFollowJumpTrampoline so it
no longer relies on byte-for-byte stub templates either, and delete
the RuntimeSpecificData class along with the per-runtime-version
template cache from both IntelDisassembler and Arm64Disassembler.
- Make the Arm64 precode/stub resolver tolerant of register-allocation
changes: accept any LDR Xa + LDR Xb + BR (Xa|Xb) triple for
StubPrecode and use the BR's register to decide which LDR loaded
Target vs MethodDesc; FixupPrecode similarly matches any LDR Xa +
BR Xa + LDR Xb. CallCountingStub validates only that the LDRH's base
register matches the preceding LDR's destination.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* Restore fixed-register matching on Arm64 per reviewer feedback
The runtime's stub ABI pins which scratch registers the precode/stub
templates use (x10/x12 for StubPrecode, x11/x12 for FixupPrecode, x9
for CallCountingStub), so generalising over them was unnecessary.
Restore the strict register checks; the actual Arm64 bug being fixed
was the LDRH encoding constant, which is now 0x7940012A (Rt=10) — the
previous value of 0x79400129 had Rt=9, so CallCountingStub recognition
never matched.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* Recognise FixupPrecodeCode_Fixup shape on Arm64
The AArch64 runtime emits two FixupPrecode shapes: the post-backpatch
form (LDR x11, Target ; BR x11 ; LDR x12, MethodDesc) and the
pre-backpatch FixupPrecodeCode_Fixup form (LDR x12, MethodDesc ;
LDR x11, PrecodeFixupThunk ; BR x11). The resolver only matched the
former, so a call site that has never been routed through the JIT'd
entry point (e.g. a guarded call that never executes during workload)
stayed unresolved and the callee was never enqueued for disassembly.
Add the missing pattern and resolve via the MethodDesc slot loaded
into x12.
Fixes CanDisassembleInlinableBenchmarks on Arm64 .NET 8 Release, where
__ForDisassemblyDiagnoser__'s `if (notEleven == 11) base.JustReturn()`
guard means the call site never executes and the slot still points at
the fixup-thunk precode.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Restore runtime-source pointer comments and drop unused helper
Re-add the "See dotnet/runtime src/coreclr/vm/{arch}/thunktemplates"
references that the previous refactor lost when the byte-template
classes were deleted, and remove ImmutableConfig.HasDisassemblyDiagnoser
now that ProcessExtensions no longer needs to gate CallCountingDelayMs
on disassembly being requested.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
0 commit comments