We should probably just delete this test when tests for #124238 are
added, but let's at least make it less expensive for now.

Bad merge of two PRs at once.
#124132 - introduced a VN cache to
find out if we have any assertions for a VN. And
#124242 introduced a VN
decomposition inside MergeEdgeAssertion loop where it tries to match
VNF_ADD(X, CNS). So the fix is to register VNF_ADD's op1 VN as well.

As the result, #124242 couldn't
find the matching assertion and the FILECHECK test failed due to bounds
check in the codegen.

…4168)

On desktop, for example, this enables building the runtime with
`./build.sh -subset clr -c Release -dynamiccodecompiled false`.

This configures the runtime to behave very similar to what would run on
iOS, where we are not allowed to generate dynamic executable code. This
configuration mainly disables jit, enables interpreter, enables cached
interface dispatch, sets `IsDynamicCodeCompiled` to false, enables
cached interface dispatch support in `crossgen2` compiled images.

This option is meant to be used for convenience, when doing perf testing
or bug investigation, without having to build/deploy for actual devices.

…#124340)

…sData() (#124293)

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: stephentoub <[email protected]>
Co-authored-by: jkotas <[email protected]>

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: adamsitnik <[email protected]>
Co-authored-by: Stephen Toub <[email protected]>
Co-authored-by: jkotas <[email protected]>
Co-authored-by: Jan Kotas <[email protected]>

PR "fixes" (actually add missing support) [#80724
WebApplication.CreateBuilder ignores
Logging:EventLog:SourceName](#80724).
It does not require any change to public facing API, but I consider it
behavioral "breaking" change. Do I need to follow some process? (I am
new in this repo). Implementation is done to be on par with Console
loggers.

There are few points which brings some questions in advance:

- Console loggers need to scope configuration under "FormatterOptions"
which comes from layered design of ConsoleLogger. Current proposal do
not require "FormatterOptions" for EventLogLogger but we can consider so
for having options scoped the same accross loggers.
- For historical reason it is called Settings, not Options. I named it
`EventLogConfigureSettings` to maintain convention, but we can consider
EventLogConfigureOptions which will better indicate that it actually
implements IConfigure**Options** and will match Console logger
convention. It is internal though.
- EventLogSettings has members Filter and EventLog which config binding
source generator (or future ones) can mess with.
- Config is not bound when legacy depracted extension methods are used,
but this is on par with Console loggers.

Fixes #80724

---------

Co-authored-by: Tarek Mahmoud Sayed <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Tarek Mahmoud Sayed <[email protected]>

We were lucking out previously that this worked with native AOT. With
runtime async, this pattern is running out of luck, likely because we're
able to optimize more.

In #122526 this test is failing with:

```
[FAIL] System.Net.Mail.Tests.MailMessageTest.SendMailMessageTest
System.ArgumentNullException : Value cannot be null.
   at System.Reflection.Runtime.MethodInfos.RuntimeNamedMethodInfo`1.MakeGenericMethod(Type[]) in /_/src/coreclr/nativeaot/System.Private.CoreLib/src/System/Reflection/Runtime/MethodInfos/RuntimeNamedMethodInfo.cs:line 134
   at System.Net.Mail.Tests.MailMessageTest.DecodeSentMailMessage(MailMessage mail) in /_/src/libraries/System.Net.Mail/tests/Functional/MailMessageTest.cs:line 268
   at System.Net.Mail.Tests.MailMessageTest.SendMailMessageTest() in /_/src/libraries/System.Net.Mail/tests/Functional/MailMessageTest.cs:line 157
   at System.Reflection.DynamicInvokeInfo.Invoke(Object, IntPtr, Object[], BinderBundle, Boolean) in /_/src/coreclr/nativeaot/System.Private.CoreLib/src/System/Reflection/DynamicInvokeInfo.cs:line 230
```

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: stephentoub <[email protected]>

If a GDV is in a must keep block (say first block of a try) we were
propagating this to all the new blocks added for a GDV.

…rty is undefined (#123133)

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: stephentoub <[email protected]>
Co-authored-by: Stephen Toub <[email protected]>

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: stephentoub <[email protected]>

Fixes #123544

…23435)

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: stephentoub <[email protected]>

[Diffs](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1290764&view=ms.vss-build-web.run-extensions-tab)

Same as #93531, but enabled for
global AP only due to CSE issue.

---------

Co-authored-by: Copilot <[email protected]>

…d StackTraceHiddenAttribute (#123686)

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: stephentoub <[email protected]>
Co-authored-by: Stephen Toub <[email protected]>

…23411)

* Adds PInvokeStubManager to handle ILStubs which now show up as PInvokeMethodDescs
* Modify `fIsILStub -> fIsInteropStub` and add `MethodDesc::IsInteropStub()`

Adds `ValueSize` class for handling sizes that may be unknown at compile
time during phases such as value numbering, that aren't concerned with
the exact numeric value (only properties such as equivalence etc.). Adds
various assertions to areas of value numbering and SSA building with
assumptions based on exact size values. Adds `LclVarDsc::lvValueSize` to
produce a `ValueSize` for a local variable, which provides the criteria
for which locals have unknown size at compile time.

When recording relocations we should not try to emit proper immediates
for address computations. Those immediates are meaningless since the
address isn't the final location, and they can cause asserts due to not
being encodable.

Fix #124327

Saves a bit of code size for unoptimized methods.

Also we should not see GT_ARR_ELEM post-morph.

---------

Co-authored-by: SingleAccretion <[email protected]>

…123752)

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: stephentoub <[email protected]>
Co-authored-by: tarekgh <[email protected]>

…natives (#124359)

Follow-up to #124240 with three improvements to the ci-analysis skill:

### Changes

**MSBuild cross-platform guidance** (build-progression-analysis.md)
- Added anti-pattern warning about MSBuild property path separator
differences (`;` vs `:`) when comparing binlogs across Windows/Linux
Helix queues
- This is a common false positive in build progression analysis

**Merge commit shortcut for target SHA extraction**
(build-progression-analysis.md)
- Added Step 2b shortcut: `gh api
repos/{owner}/{repo}/git/commits/{sourceVersion} --jq '.parents[0].sha'`
- Extracts target branch HEAD from the merge commit's first parent —
much simpler than parsing checkout logs
- Noted caveat: only works for the latest build (GitHub recomputes merge
ref on each push)
- Added `get_commit` MCP tool as alternative when available

**Inline MCP tool alternatives** (all 4 files)
- Added `pull_request_read` as alternative to `gh pr checks` in SKILL.md
- Added `search_issues` MCP note in azdo-helix-reference.md
- Added `get_commit` MCP note in build-progression-analysis.md
- Reframed azure-cli.md with one-sentence MCP-first preamble

All changes are minimal inline additions — no structural changes to the
skill.

Signed-off-by: AraHaan <[email protected]>
Co-authored-by: Jeremy Barton <[email protected]>
Co-authored-by: Kevin Jones <[email protected]>
Co-authored-by: Stephen Toub <[email protected]>

* Add various relocation types from the wasm linking spec to CorInfoReloc and RelocType
* Add new instruction formats for relocated constant payloads like IF_FUNCIDX and IF_MEMADDR
* Use relocations in emitIns_Call
* Add pseudo-instructions for relocated i32_const
* Make WasmTypeNode an ISymbolNode so it can be a reloc target

For linux-arm and linux-arm64 we build parts of SPMI for x64 since the
build machines are x64 hosted and we need to run mcs on those. However,
this build would fail because of NuGet authentication issues in the
target container.

…124814)

## Description

Argument and pointer validation checks at the start of `SOSDacImpl`
methods were returning early (before the `try/catch`), bypassing the
catch block's HResult conversion and the `#if DEBUG` legacy comparison
block.

### Changes

- **E_INVALIDARG checks** → moved inside `try`, replaced `return
HResults.E_INVALIDARG` with `throw new ArgumentException()`
- **E_POINTER checks** → moved inside `try`, replaced `return
HResults.E_POINTER` with `throw new NullReferenceException()`
- **`if/else` guard patterns** (ISOSDacInterface14 methods,
`GetILForModule`, `GetMethodDescFromToken`, `TraverseModuleMap`) →
flattened into unified `try/catch` with throws
- **Switch `default:` cases** (`GetMethodDescFromToken`,
`TraverseModuleMap`) → replaced `hr = HResults.E_INVALIDARG` with `throw
new ArgumentException()` so execution halts rather than falling through
- **`GetPEFileName`** → inner `return HResults.E_NOTIMPL` inside `try`
replaced with `throw new NotImplementedException()` to prevent
`CopyStringToBuffer` from running on empty paths
- **`SOSMethodEnum.GetCount`** → added `try/catch` wrapper; `return
HResults.E_POINTER` → `throw new NullReferenceException()`
- **`GetThreadFromThinlockID`** → fixed latent bug: null check was
setting `hr` but not preventing the `try` block from running, causing
`*pThread` dereference on a null pointer

**Before / After pattern:**
```csharp
// Before — bypasses catch and #if DEBUG block
int ISOSDacInterface.GetThreadData(ClrDataAddress thread, DacpThreadData* data)
{
    if (thread == 0 || data == null)
        return HResults.E_INVALIDARG;   // skips try/catch and DEBUG comparison

    int hr = HResults.S_OK;
    try { ... }
    catch (Exception ex) { hr = ex.HResult; }
    ...
}

// After — check participates in unified error handling
int ISOSDacInterface.GetThreadData(ClrDataAddress thread, DacpThreadData* data)
{
    int hr = HResults.S_OK;
    try
    {
        if (thread == 0 || data == null)
            throw new ArgumentException();
        ...
    }
    catch (Exception ex) { hr = ex.HResult; }
    ...
}
```

## Testing

- All 832 existing cDAC unit tests pass.

<!-- START COPILOT CODING AGENT TIPS -->
---

✨ Let Copilot coding agent [set things up for
you](https://github.com/dotnet/runtime/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot)
— coding agent works faster and does higher quality work when set up for
your repo.

---------

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: rcj1 <[email protected]>

Follow up to #123526. We need to preserve r2 that may have the async
continuation. The newly added line would clobber it before we preserve
it in `RhpWaitForGc`.

)

Add support for internal registers.

Use these to implement overflow checks for ADD/SUB/MUL, where the result
of the operation is multiply used (though for long MUL, defer to a
runtime helper).

---------

Co-authored-by: Copilot <[email protected]>

For the following code:
```
struct MyStruct
{
   public int Value;
}

static string CallToString<T>(ref T val) where T : struct
{
   // constrained. T callvirt ToString()
   return val.ToString();
}

var s = new MyStruct { Value = 42 };
Console.WriteLine(CallToString(ref s));
```

The CallToString method would be skipped by r2r because, in this state,
if user would change MyStruct to contain an override for `ToString` then
the generated code for CallToString would be incorrect since it should
no longer do any boxing. For composite r2r however, this is not a
problem if the valuetype (MyStruct) and the compiled method
(CallToString) are in the same version bubble. The fix adds a check that
these are in the same version bubble.

…ROS<string>. (#124792)

…ms`, `scoped`, and ref struct parameters (#124589)

The `LoggerMessage` source generator dropped the `ref readonly` modifier
from generated implementations (causing CS0758), and silently accepted
`params`, `scoped`, and ref struct parameters that either produce
confusing semantics or fail to compile when stored in the generated
>6-parameter struct.

## Description

- **Parser**
- Preserve `ref readonly`: use `RefKind.RefReadOnlyParameter` under `#if
ROSLYN4_8_OR_GREATER`, fall back to `(RefKind)4`
- Emit **SYSLIB1028** (`InvalidLoggingMethodParameterParams`) for
`params` or `scoped` parameters (scoped detection guarded by `#if
ROSLYN4_4_OR_GREATER`)
- Emit **SYSLIB1029** (`InvalidLoggingMethodParameterRefStruct`) for any
ref struct parameter (`paramTypeSymbol.IsRefLikeType`), including `ref
ReadOnlySpan<T>`, `scoped ReadOnlySpan<T>`, etc.
- Both new checks run before `typeName` allocation to avoid unnecessary
string work on failure paths

- **Emitter**: emit `in`/`ref`/`ref readonly` qualifier correctly in
generated parameter list

- **Resources**: `Strings.resx` + all 13 xlf files updated with
SYSLIB1028 and SYSLIB1029 message strings

- **Docs**: `docs/project/list-of-diagnostics.md` updated with
SYSLIB1028 and SYSLIB1029 entries

- **Tests**
- `RefReadOnlyParameterOK`, `RefReadOnlyParameterWithMoreThan6ParamsOK`
— verify modifier is preserved
- `InvalidParamsParameter`, `InvalidParamsCollectionParameter` —
SYSLIB1028 for `params T[]` and `params IEnumerable<T>`
- `InvalidScopedRefParameter`, `InvalidScopedRefReadOnlyParameter` —
SYSLIB1028 for `scoped ref T` variants
- `InvalidRefLikeTypeParameter`, `InvalidScopedValueParameter` —
SYSLIB1029 for ref struct parameters
- Emitter baseline test `TestBaseline_TestWithRefReadOnlyParam_Success`

```csharp
// ref readonly is now preserved in the generated implementation
[LoggerMessage(Message = "{p}", Level = LogLevel.Info)]
static partial void Log(ILogger l, ref readonly int p);
// → ref readonly global::System.Int32 p  ✓

// params and scoped are now compile-time errors (SYSLIB1028)
static partial void Log(ILogger l, params object?[] args);
static partial void Log(ILogger l, scoped ref int p);

// ref struct parameters are now a compile-time error (SYSLIB1029)
static partial void Log(ILogger l, ref MyRefStruct s);
```

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>


----

*This section details on the original issue you should resolve*

<issue_title>Source generation error in LoggerMessageAttribute in
Microsoft.Extensions.Logging.Abstractions</issue_title>
<issue_description>### Description

Using 'params' keyword in method parameters "params object?[] args" in
partial class under [LoggerMessage] attribute cause Compiler Error
CS0758 - in generated code 'params' keyword is absent

### Reproduction Steps

```c#
using Microsoft.Extensions.Logging;

internal static partial class LogMessages
{
    [LoggerMessage(Message = "Message: {message}, {args}", Level = LogLevel.Information)]
    internal static partial void MSG(this ILogger logger, string? message, params object?[] args);
}

```



### Expected behavior

Compile

### Actual behavior

in source-generated file LoggerMessage.g.cs, 'params' keyword is absent
in method parameters "global::System.Object?[] args"

```c#
partial class LogMessages
{
    [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.Extensions.Logging.Generators", "7.0.7.1805")]
    private static readonly global::System.Action<global::Microsoft.Extensions.Logging.ILogger, global::System.String?, global::System.Object?[], global::System.Exception?> __MSGCallback =
        global::Microsoft.Extensions.Logging.LoggerMessage.Define<global::System.String?, global::System.Object?[]>(global::Microsoft.Extensions.Logging.LogLevel.Information, new global::Microsoft.Extensions.Logging.EventId(-1, nameof(MSG)), "Message: {message}, {args}", new global::Microsoft.Extensions.Logging.LogDefineOptions() { SkipEnabledCheck = true }); 

    [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.Extensions.Logging.Generators", "7.0.7.1805")]
    internal static partial void MSG(this global::Microsoft.Extensions.Logging.ILogger logger, global::System.String? message, global::System.Object?[] args)
    {
        if (logger.IsEnabled(global::Microsoft.Extensions.Logging.LogLevel.Information))
        {
            __MSGCallback(logger, message, args, null);
        }
    }
}
```


### Regression?

_No response_

### Known Workarounds

_No response_

### Configuration

.NET 7.0
Windows 10 x64
Visual Studio Community 2022

### Other information

_No response_</issue_description>

<agent_instructions>Add support for params (including params
collections) in logging methods. Add tests verifying it
works.</agent_instructions>

## Comments on the Issue (you are @copilot in this section)

<comments>
<comment_new><author>@</author><body>
Tagging subscribers to this area: @dotnet/area-extensions-logging
See info in
[area-owners.md](https://github.com/dotnet/runtime/blob/main/docs/area-owners.md)
if you want to be subscribed.
<details>
<summary>Issue Details</summary>
<hr />

### Description

Using 'params' keyword in method parameters "params object?[] args" in
partial class under [LoggerMessage] attribute cause Compiler Error
CS0758 - in generated code 'params' keyword is absent

### Reproduction Steps

```
using Microsoft.Extensions.Logging;

internal static partial class LogMessages
{
    [LoggerMessage(Message = "Message: {message}, {args}", Level = LogLevel.Information)]
    internal static partial void MSG(this ILogger logger, string? message, params object?[] args);
}

```



### Expected behavior

Compile

### Actual behavior

in source-generated file LoggerMessage.g.cs, 'params' keyword is absent
in method parameters "global::System.Object?[] args"

```
partial class LogMessages
{
    [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.Extensions.Logging.Generators", "7.0.7.1805")]
    private static readonly global::System.Action<global::Microsoft.Extensions.Logging.ILogger, global::System.String?, global::System.Object?[], global::System.Exception?> __MSGCallback =
        global::Microsoft.Extensions.Logging.LoggerMessage.Define<global::System.String?, global::System.Object?[]>(global::Microsoft.Extensions.Logging.LogLevel.Information, new global::Microsoft.Extensions.Logging.EventId(-1, nameof(MSG)), "Message: {message}, {args}", new global::Microsoft.Extensions.Logging.LogDefineOptions() { SkipEnabledCheck = true }); 

    [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.Extensions.Logging.Generators", "7.0.7.1805")]
    internal static partial void MSG(this global::Microsoft.Extensions.Logging.ILogger logger, global::System.String? message, global::System.Object?[] args)
    {
        if (logger.IsEnabled(global::Microsoft.Extensions.Logging.LogLevel.Information))
        {
            __MSGCallback(logger, message, args, null);
        }
    }
}
```


### Regression?

_No response_

### Known Workarounds

_No response_

### Configuration

.NET 7.0
Windows 10 x64
Visual Studio Community 2022

### Other information

_No response_

<table>
  <tr>
    <th align="left">Author:</th>
    <td>abrca</td>
  </tr>
  <tr>
    <th align="left">Assignees:</th>
    <td>-</td>
  </tr>
  <t...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes #91678

<!-- START COPILOT CODING AGENT TIPS -->
---

💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.

---------

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: svick <[email protected]>
Co-authored-by: tarekgh <[email protected]>

Running out of consecutive registers for arm64 under jit reg stress.
Lsra is trying to place `C380, C381, V363, V364` into four consecutive
registers `d31, d0, d1, d2` for a VectorTableLookup (TBL) and runs out
of registers when trying to assign V364 as `d2`.

LSRA can normally handle this wraparound. Issue is that the C381 def
also occupies d2, so d2 is incorrectly considered not available for
V364. Normally this conflict is handled by the
`LinearScan::consecutiveRegsInUseThisLocation` mask - but the way the
mask is calculated does not handle the d31->d0 wraparound properly.

fixes #124357

---------

Co-authored-by: Copilot <[email protected]>

…24786)

This PR adds support for building and testing CoreCLR on browser-wasm in
the performance pipeline, alongside the existing Mono builds.

Changes:

Add a new build job in `perf-wasm-build-jobs.yml` for CoreCLR targeting
browser_wasm with artifact name BrowserWasmCoreCLR.
Parameterize `perf-wasm-prepare-artifacts-steps.yml` with runtimeFlavor
and artifactName to support both runtimes
CoreCLR artifacts are smaller (only runtime pack needed) vs Mono (full
SDK + nugets)
This enables running wasm benchmarks with `--wasm-coreclr` to compare
performance between the two runtimes.

## Summary

Fix `Sec_Application_Protocols.ProtocolListSize` field type from `short`
to `ushort` to match the native Windows `SEC_APPLICATION_PROTOCOL_LIST`
struct (`USHORT`), and add tests for ALPN list size validation.

## Changes

### Bug fix
- **`Interop.Sec_Application_Protocols.cs`**: Changed `ProtocolListSize`
from `short` to `ushort` and updated the aggregate size limit from
`short.MaxValue` (32,767) to `ushort.MaxValue` (65,535), aligning with
both the native Windows API and the RFC 7301 TLS wire format.

### Tests
- **`SslStreamAlpnTests.cs`**: Added
`SslStream_StreamToStream_AlpnListTotalSizeExceedsLimit_Throws` —
verifies that exceeding the 65,535-byte aggregate ALPN list limit
throws:
- `ArgumentException` on Windows (managed validation in
`GetProtocolLength()`)
- `AuthenticationException` on Linux/FreeBSD (OpenSSL fails during
ClientHello construction)
- **`SslApplicationProtocolTests.cs`**: Added boundary tests for
individual protocol sizes (0, 1, 254, 255, 256, 512 bytes) via both
`byte[]` and `string` constructors.

---------

Co-authored-by: Copilot <[email protected]>

Opus highlighted these as potential issues.

We pass IntPtr fields to native callbacks, but we don't root the object
holding them (it's possible that it's implicitly is done by
GC.KeepAlive(this), but I wasn't able to prove that).

Co-authored-by: egorbot <[email protected]>

Required for xunit v3 and the other ctor is marked obsolete as of
dotnet/arcade#16537

* Adding GetCodeHeaderData cDAC API
* Implementing unwind data size on platforms other than x86 in helper
class
* required additions to hot/cold lookup helpers
* Implements IGCInfo contract to decode GCInfo
* Currently supports x64, arm64, and arm. I plan to move the existing
x86 GCInfo decoding to this new contract, but want to make that a
separate PR.

Fixes #124687

---------

Co-authored-by: rcj1 <[email protected]>
Co-authored-by: Max Charlamb <[email protected]>

## Description

Implements `GetRegisterName` in `SOSDacImpl.cs` using the `RuntimeInfo`
contract instead of delegating to the legacy DAC. This mirrors the logic
in `ClrDataAccess::GetRegisterName` (`request.cpp`) but uses
`IRuntimeInfo.GetTargetArchitecture()` at runtime to select register
names, rather than compile-time `#ifdef` guards.

### Implementation (`SOSDacImpl.cs`)
- Register name arrays for X64, X86, ARM, ARM64, LoongArch64, RiscV64
matching the C++ source
- Caller frame encoding: negative `regNum` → `"caller.<reg>"` via
`-(reg+1)`, using a separate `regIndex` local to avoid mutating the
parameter
- `NullReferenceException` thrown inside the try block when both
`buffer` and `pNeeded` are null (HResult maps to `E_POINTER`), following
the established pattern in the file (e.g., `IsRCWDCOMProxy`)
- `E_UNEXPECTED` for out-of-range register index
- `S_FALSE` when buffer is too small (partial copy via
`OutputBufferHelpers`)
- `#if DEBUG` legacy DAC comparison using the unmutated `regName`
parameter directly

### Tests (`GetRegisterNameTests.cs`)
- 32 tests covering all 6 architectures, caller frame prefix, null/small
buffer handling, out-of-range indices, and unsupported architecture
(Wasm)

Fixes #124823

---------

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: max-charlamb <[email protected]>

…acImpl (#124805)

## Description

Implements `GetGlobalAllocationContext` in the cDAC `SOSDacImpl`,
matching the native `ClrDataAccess::GetGlobalAllocationContext` in
`request.cpp`. The implementation is routed through the GC contract
layer. Adds a dump test using the GCRoots debuggee.

### Changes

- **VM data descriptor** (`datadescriptor.inc`): Expose
`g_global_alloc_context` as `CDAC_GLOBAL_POINTER(GlobalAllocContext,
...)`
- **Constants.cs**: Add `GlobalAllocContext` global name constant
- **IGC.cs**: Add `GetGlobalAllocationContext(out TargetPointer
allocPtr, out TargetPointer allocLimit)` to the `IGC` contract interface
- **GC_1.cs**: Implement `GetGlobalAllocationContext` using
`EEAllocContext`/`GCAllocContext` Data types via
`ProcessedData.GetOrAdd`
- **SOSDacImpl.cs**: Replace legacy-only delegation with cDAC
implementation that calls
`_target.Contracts.GC.GetGlobalAllocationContext()`, using
`ArgumentException` for null parameter validation inside the try block
and `#if DEBUG` legacy comparison with `default`-initialized locals
- **GC.md**: Document the `EEAllocContext` data descriptor type,
`GlobalAllocContext` global variable, new API signature, and pseudocode
implementation
- **WorkstationGCDumpTests.cs**: Add
`WorkstationGC_GlobalAllocationContextIsReadable` test validating the
global is readable via the contract layer and `allocPtr <= allocLimit`

The implementation reads the global pointer through the GC contract,
which navigates `EEAllocContext` → `GCAllocContext` using the internal
Data types, then extracts `Pointer` and `Limit` — mirroring how the
native DAC dereferences
`((ee_alloc_context)g_global_alloc_context).m_GCAllocContext`.

Fixes #124824

---------

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: max-charlamb <[email protected]>

…read_DefaultStackSize for setting stack size. (#124588)

This increases the default stack size on s390x and ppc64le. Due to
missing implementation for tail call optimization, the vmr build exhaust
the stack while building the fsharp repo. With an 8MB stack, the build
can complete.

Additionally this adds support for a user to control the stack size
using the DOTNET_Thread_DefaultStackSize envvar.

Fixes #124368.

@jkotas @akoeplinger @hamarb123 ptal.

---------

Co-authored-by: Alexander Köplinger <[email protected]>

…#124813)

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: vcsjones <[email protected]>
Co-authored-by: stephentoub <[email protected]>

… byte offset (#124845)

## Description

During epilogue emulation in the managed cDAC AMD64 unwinder, the
register number for single-byte `pop r64` instructions (registers 0–7)
was extracted from `nextByte + 2` instead of `nextByte`. Since `pop r64`
is a single-byte opcode (`0x58 + r`), the register is encoded in the low
3 bits of the opcode byte itself — reading two bytes ahead returns an
arbitrary instruction stream byte, silently corrupting the unwound
register context and potentially cascading into wrong instruction
pointers in subsequent frames.

### Fix

```csharp
// Before (wrong — reads 2 bytes past the opcode)
byte registerNumber = (byte)(ReadByteAt(nextByte + 2) & 0x7);

// After (correct — matches native dbs_stack_x64.cpp: RegisterNumber = NextByte[0] & 0x7)
byte registerNumber = (byte)(ReadByteAt(nextByte) & 0x7);
```

The REX-prefix pop case (registers 8–15) and the non-epilogue
epilogue-detection scan are both correct and unaffected.

## Changes

- **`AMD64Unwinder.cs` line 479**: Change `ReadByteAt(nextByte + 2)` →
`ReadByteAt(nextByte)` to correctly extract the register number from the
`pop r64` opcode byte, matching the native unwinder in
`dbs_stack_x64.cpp`.

…124848)

Three correctness bugs found by auditing the cDAC managed unwinders
against their native C++ counterparts in `dbs_stack_x64.cpp` /
`gc_unwind_x86.inl`.

## Description

- **`UWOP_PUSH_MACHFRAME` sets `machineFrame = false` instead of `true`
(high severity)**
`UnwindPrologue` checks `if (!machineFrame)` at the end to decide
whether to read RIP from RSP and advance RSP. With the wrong value,
unwinding through interrupt/trap frames double-reads the return address,
corrupting both RIP and RSP. Native ref: `dbs_stack_x64.cpp:381` sets
`MachineFrame = TRUE`.

- **`UWOP_SAVE_NONVOL_FAR` case missing from `UnwindPrologue` switch
(medium severity)**
Without a matching case, the opcode falls through to `Debug.Fail` — the
nonvolatile register is never restored and the two extra index slots are
not consumed, corrupting subsequent unwind code parsing. Added the case
to read the 32-bit displacement from slots `index+1`/`index+2` and
restore the register, matching `dbs_stack_x64.cpp:265–279`.

- **Stale `Console.WriteLine(methodStart)` in
`X86Unwinder.UnwindEspFrame` (low severity)**
Debug leftover with no native equivalent; emits stdout noise on every
ESP frame unwind. Removed.

…nd add P/Invoke dump tests (#124783)

## Summary

Fix `GetILAddressMap` and `GetILOffsetsByAddress` in the cDAC to return
`E_FAIL` (matching the legacy DAC) when a method has no debug info, and
add dump-based integration tests exercising ILStub and VarargPInvoke
stack frames.

## Problem

ILStubs are JIT-compiled but the JIT does not generate debug metadata
for them — their `RealCodeHeader.DebugInfo` pointer is null. When SOS
commands like `!clru -il` call `GetILAddressMap` on an ILStub:

- **Legacy DAC**: `ClrDataAccess::GetMethodNativeMap` calls
`DebugInfoManager::GetBoundariesAndVars`, which returns `FALSE` ->
returns `E_FAIL` (0x80004005). This propagates through `GetILAddressMap`
without ever reaching the `E_NOINTERFACE` path.
- **cDAC (before this fix)**: `DebugInfo_1/2.GetMethodNativeMap`
attempted to read from the null debug info pointer ->
`VirtualReadException` (0x80131c49) escaped through `catch (Exception
ex) { hr = ex.HResult; }`, producing an HResult that doesn't match the
DAC.

This caused `Debug.Assert(hrLocal == hr)` failures in CI when running
SOS tests against the cDAC.

## Fix

### Contract change: `HasDebugInfo` API and non-nullable
`GetMethodNativeMap`

The DAC has two distinct failure paths for empty/missing debug info:

| Scenario | DAC behavior | HResult |
|----------|-------------|---------|
| No debug info exists (ILStubs) | `GetBoundariesAndVars` returns
`FALSE` | `E_FAIL` (0x80004005) |
| Debug info exists, zero entries | `numMap == 0` after successful
retrieval | `E_NOINTERFACE` (0x80004002) |

To avoid having a nullable return on `GetMethodNativeMap` (where `null`
vs empty is a subtle distinction), the fix adds a new `bool
HasDebugInfo(TargetCodePointer pCode)` API to the `IDebugInfo` contract.
This lets callers explicitly check for the existence of debug info
before calling `GetMethodNativeMap`, which always returns a non-nullable
`IEnumerable<OffsetMapping>` (empty when no debug info exists).

In `ClrDataMethodInstance`, both `GetILOffsetsByAddress` and
`GetILAddressMap` call `HasDebugInfo` first and throw `E_FAIL` when it
returns `false`, matching the legacy DAC behavior.

## New dump tests

### Test infrastructure

- **`DumpInfo`** — Metadata class that records OS/arch in
`dump-info.json` alongside dumps, enabling platform-aware test skipping.
- **`SkipOnOSAttribute`** — `[SkipOnOS(IncludeOnly = "windows")]` skips
tests when the dump wasn't generated on the specified OS. Supports both
exclude and include-only modes.
- **`DumpTests.targets`** — MSBuild target that auto-generates
`dump-info.json` during dump creation.

### Debuggees

- **`VarargPInvoke`** — Calls `sprintf` via `__arglist`, triggering the
`VarargPInvokeStub` assembly thunk path. Crashes inside native code so
the stub frame is on the stack.
- **`PInvokeStub`** — Uses `SetLastError=true` on a P/Invoke to force an
ILStub `DynamicMethodDesc`. Crashes inside `memcpy` with null args.

…4361)

…apLevel (#124862)

## Summary

One-line fix: invert the IsNull() condition in the template overload of
EnumMemoryRangeSectionMapLevel to match the non-template L1 overload.

## Problem

The template overload of `EnumMemoryRangeSectionMapLevel` (handling
levels L2–L5 on 64-bit) has an inverted condition at line 1553 of
`codeman.h`:

```cpp
// BUG: recurses into NULL entries, skips populated ones
if (level[i].IsNull())
{
    EnumMemoryRangeSectionMapLevel(flags, *level[i].VolatileLoad(pLockState), pLockState);
}
```

The non-template L1 overload at line 1538 correctly uses \!IsNull()\:

```cpp
// CORRECT: only recurse into populated entries
if (!level[i].IsNull())
{
    EnumMemoryRangeSectionMapLevel(flags, level[i], pLockState);
}
```

This bug means `EnumMemoryRegions` for the `RangeSectionMap` never
enumerates anything below the top level on 64-bit (where levels L2–L5
use the template), and attempts to dereference null pointers for empty
slots. This could cause incomplete DAC memory enumeration during dump
generation.

Co-authored-by: Max Charlamb <[email protected]>
Co-authored-by: Copilot <[email protected]>

> [!NOTE]
> This is a codeflow update. It may contain both source code changes
from
> [the VMR](https://github.com/dotnet/dotnet)
> as well as dependency updates. Learn more
[here](https://github.com/dotnet/dotnet/tree/main/docs/Codeflow-PRs.md).

This pull request brings the following source code changes


[marker]: <> (Begin:f7901f87-9f24-40d6-9bc1-564863937237)

## From https://github.com/dotnet/dotnet
- **Subscription**:
[f7901f87-9f24-40d6-9bc1-564863937237](https://maestro.dot.net/subscriptions?search=f7901f87-9f24-40d6-9bc1-564863937237)
- **Build**:
[20260224.2](https://dev.azure.com/dnceng/internal/_build/results?buildId=2911474)
([303174](https://maestro.dot.net/channel/8298/github:dotnet:dotnet/build/303174))
- **Date Produced**: February 24, 2026 2:34:05 PM UTC
- **Commit**:
[36ea4de4a4409ace6bdf48c2dae2b6713f47c1b9](dotnet/dotnet@36ea4de)
- **Commit Diff**:
[6699c73...36ea4de](dotnet/dotnet@6699c73...36ea4de)
- **Branch**: [main](https://github.com/dotnet/dotnet/tree/main)

**Updated Dependencies**
- From [5.5.0-2.26117.101 to 5.5.0-2.26124.102][2]
  - Microsoft.CodeAnalysis
  - Microsoft.CodeAnalysis.Analyzers
  - Microsoft.CodeAnalysis.CSharp
  - Microsoft.Net.Compilers.Toolset
- From [11.0.100-preview.2.26117.101 to 11.0.100-preview.3.26124.102][2]
  - Microsoft.CodeAnalysis.NetAnalyzers
  - Microsoft.DotNet.ApiCompat.Task
- Microsoft.NET.Workload.Emscripten.Current.Manifest-11.0.100.Transport
- From [11.0.0-beta.26117.101 to 11.0.0-beta.26124.102][2]
  - Microsoft.DotNet.Arcade.Sdk
  - Microsoft.DotNet.Build.Tasks.Archives
  - Microsoft.DotNet.Build.Tasks.Feed
  - Microsoft.DotNet.Build.Tasks.Installers
  - Microsoft.DotNet.Build.Tasks.Packaging
  - Microsoft.DotNet.Build.Tasks.TargetFramework
  - Microsoft.DotNet.Build.Tasks.Templating
  - Microsoft.DotNet.Build.Tasks.Workloads
  - Microsoft.DotNet.CodeAnalysis
  - Microsoft.DotNet.GenAPI
  - Microsoft.DotNet.GenFacades
  - Microsoft.DotNet.Helix.Sdk
  - Microsoft.DotNet.PackageTesting
  - Microsoft.DotNet.RemoteExecutor
  - Microsoft.DotNet.SharedFramework.Sdk
  - Microsoft.DotNet.XliffTasks
  - Microsoft.DotNet.XUnitExtensions
- From [0.11.5-preview.26117.101 to 0.11.5-preview.26124.102][2]
  - Microsoft.DotNet.Cecil
- From [2.9.3-beta.26117.101 to 2.9.3-beta.26124.102][2]
  - Microsoft.DotNet.XUnitAssert
  - Microsoft.DotNet.XUnitConsoleRunner
- From [11.0.0-preview.2.26117.101 to 11.0.0-preview.3.26124.102][2]
  - Microsoft.NET.Sdk.IL
  - Microsoft.NETCore.App.Ref
  - Microsoft.NETCore.ILAsm
  - runtime.native.System.IO.Ports
  - System.Reflection.Metadata
  - System.Reflection.MetadataLoadContext
  - System.Text.Json
- From [7.5.0-rc.11801 to 7.5.0-rc.12502][2]
  - NuGet.Frameworks
  - NuGet.Packaging
  - NuGet.ProjectModel
  - NuGet.Versioning
- From [3.0.0-preview.2.26117.101 to 3.0.0-preview.3.26124.102][2]
  - System.CommandLine
- From [19.1.0-alpha.1.26109.1 to
19.1.0-alpha.1.26116.1](dotnet/dotnet@9b07aad...9b44df5)
  - runtime.linux-arm64.Microsoft.NETCore.Runtime.JIT.Tools
  - runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
  - runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
  - runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
  - runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.JIT.Tools
- runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
  - runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
  - runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
  - runtime.linux-musl-x64.Microsoft.NETCore.Runtime.JIT.Tools
  - runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
  - runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
  - runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
  - runtime.linux-x64.Microsoft.NETCore.Runtime.JIT.Tools
  - runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
  - runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
  - runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
  - runtime.osx-arm64.Microsoft.NETCore.Runtime.JIT.Tools
  - runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
  - runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
  - runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
  - runtime.osx-x64.Microsoft.NETCore.Runtime.JIT.Tools
  - runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
  - runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
  - runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
  - runtime.win-arm64.Microsoft.NETCore.Runtime.JIT.Tools
  - runtime.win-x64.Microsoft.NETCore.Runtime.JIT.Tools
  - runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
  - runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
  - runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
- From [11.0.0-alpha.1.26109.1 to
11.0.0-alpha.1.26116.1](dotnet/dotnet@d41da27...7ceff14)
  - runtime.linux-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
- runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
  - runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
  - runtime.linux-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
  - runtime.osx-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
  - runtime.osx-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
  - runtime.win-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
  - runtime.win-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport

[marker]: <> (End:f7901f87-9f24-40d6-9bc1-564863937237)


[1]: dotnet/dotnet@6699c73...b5d394e

[2]: dotnet/dotnet@6699c73...36ea4de
[marker]: <> (Start:Footer:CodeFlow PR)

## Associated changes in source repos
-
dotnet/arcade@96ff818...88c8808
-
dotnet/aspnetcore@23e6a3a...6bf45a7
-
dotnet/command-line-api@702b2bb...a3bae7d
-
dotnet/efcore@a471ebf...fb11d70
-
dotnet/fsharp@01bad01...5fd82bc
-
NuGet/NuGet.Client@e323999...a60358c
-
dotnet/razor@b786066...a1bd540
-
dotnet/roslyn@da86ec6...24ed5cb
-
a27de4a...f8ac08f
-
dotnet/sdk@e9d68d8...e90c441
-
dotnet/source-build-reference-packages@cc90bb4...d492faa
-
dotnet/sourcelink@abbd07d...6ea6adb
-
microsoft/vstest@d9ab5ad...42e97b7
-
dotnet/winforms@6ac21ae...fdb43c8

<details>
<summary>Diff the source with this PR branch</summary>

```bash
darc vmr diff --name-only https://github.com/dotnet/dotnet:36ea4de4a4409ace6bdf48c2dae2b6713f47c1b9..https://github.com/dotnet/runtime:darc-main-13a53c20-827a-4ce2-8ffb-2326c9f96f0a
```
</details>

[marker]: <> (End:Footer:CodeFlow PR)

---------

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

First part of #94425 and #94426

When adding a new group, I've added the entire group for completeness.

Plus fix up existing code:
* umull/smull etc does not have a 32bit version
* stlurb etc uses scalar registers, not vector registers
* Fix the missing bit for simd ldapur
* smaddl etc does not have a 32bit version
* sha1su1/sha256su0 were in the wrong groups, and had no tests
* cdot test immediate values were wrong
* fix some register display issues

---------

Co-authored-by: Copilot <[email protected]>

Noticed this in #124883 but I don't think it's worth it to fix it up (it
needs a fixup because the main is a global method).

See the comment. There is a bit more context on the .NET Framework side:

```
This tests that we throw an exception when trying to load a module that contains
two TypeDefs with the same name.  We must use binary post-processing to make this
happen since no compiler will allow us to define a duplicate type name.

For simplicity, we have an IL image checked in and we'll just copy it over
to testbin.  Since this is an IL image, it should always work.
However, if this image should ever stop working, the image can be reproduced
by doing the following:
1) ilasm test5.il
2) use pereader to dump the structure of test5.exe
3) Find the index into the string heap for the name of the "Foo" class, copy the index
4) Find the path to the index for the name of the "Bar" class
5) create a file like test5.cpt that writes the Foo index value onto the name index field of the Bar class
(thus, assigning the name "Foo" to the Bar type.)
6) use pewriter /source test5.exe /modify test5.cpt /out test5.cpt.exe to recreate the corrupted executable file.

When running this test, set the environment variable:
COMPLUS_DisableWatsonForManagedExceptions=1
to avoid a debugging pop-up dialog for the expected unhandled exception.
```

But basically this PE file should be modified and the test harness
expects it to crash with an unhandled exception. It is not testing
anything interesting without those steps.

…eSubdirectories (#124849)

`FileSystemWatcher_SymbolicLink_TargetsDirectory_Create_IncludeSubdirectories`
consistently fails on number of platforms and tests configurations. 
---------

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: jtschuster <[email protected]>