[wasm] Bump chrome for testing - linux: 122.0.6261.128, windows: 122.0.6261.129 - #23
Open
github-actions[bot] wants to merge 1 commit into
Open
[wasm] Bump chrome for testing - linux: 122.0.6261.128, windows: 122.0.6261.129#23github-actions[bot] wants to merge 1 commit into
github-actions[bot] wants to merge 1 commit into
Conversation
wfurt
pushed a commit
that referenced
this pull request
Apr 15, 2026
This removes the need for manually aligning the instructions in the IL stream, the encoder takes care of this when necessary.
wfurt
pushed a commit
that referenced
this pull request
Jul 21, 2026
…ns to 4 bytes (dotnet#130564) Follow-up to dotnet#129017. ## Summary That PR fixed a 32-bit ARM `SIGBUS` (`BUS_ADRALN`) in composite Ready-to-Run images caused by emitting the manifest MVID table with `alignment: 1`. The adjacent `ManifestMetadataTableNode` (the metadata root) and `AssemblyTableNode` (`ComponentAssemblies`) have the identical latent bug: both are packed arrays of `DWORD`-typed fields that the CoreCLR runtime reads in place, but both are emitted with `alignment: 1`, so they can land on a non-4-aligned RVA. On ARM32 that faults with `BUS_ADRALN` (unaligned multi-word load); x64/arm64 tolerate it, so it stayed latent until android-arm composite R2R was exercised. In the failing android-arm MAUI R2R crash (dotnet/android#12026) the MVID table was already aligned (thanks to dotnet#129017), but the **metadata root** landed on an odd RVA and faulted in `PEDecoder::CheckCorHeader` during `coreclr_initialize`. So dotnet#129017 was necessary but not sufficient for this configuration; this change completes it by aligning the remaining manifest-region sections. ## Root cause Loading a composite image parses the metadata root via `PEDecoder::CheckCorHeader`, which walks `STORAGESTREAM` headers (`ULONG iOffset; ULONG iSize; char rcName[]`). The compiler coalesces the two adjacent `DWORD` reads (`iOffset`/`iSize`) into a single `LDRD`, which requires 4-byte alignment on ARM32: ``` Fatal signal 7 (SIGBUS), code 1 (BUS_ADRALN) #00 pc ... libcoreclr.so PEDecoder::CheckCorHeader() const (pedecoder.cpp) ... #23 pc ... libcoreclr.so coreclr_initialize ``` `ComponentAssemblies` (`READYTORUN_COMPONENT_ASSEMBLIES_ENTRY`) is likewise a packed `DWORD` array read in place, and the regression test shows it landing unaligned without the fix. ## Provenance `alignment: 1` on `ManifestMetadataTableNode` dates back to the initial population of crossgen2 from the CoreRT sources (`ac857a2e`, 2019) and was never a deliberate choice — no commit or discussion in the file's history addressed alignment; the value was carried verbatim through later refactors (e.g. dotnet#71271 only switched to named arguments). The sibling `ManifestAssemblyMvidHeaderNode` shared the same default and was corrected in dotnet#129017. ## Why 4, and why not configurable / a size concern - The metadata root and component-assembly entries are all `DWORD` fields whose natural alignment is 4; ECMA-335 already pads the metadata version string so stream headers are 4-aligned within the blob. 4-byte section-start alignment is the correct requirement (same rationale as dotnet#129017's "GUID has a natural alignment of 4"). - No meaningful size impact: these are singleton sections (once per composite image), so the change adds at most 3 padding bytes per section. - Not a user-facing knob: every other crossgen2 section uses a fixed natural alignment (RuntimeFunctions=4, GCRefMap=4, …); a configurable "may emit a misaligned image" switch would be a footgun, so this stays a fixed value. ## Testing Mirrors dotnet#129017's test approach: a `CompositeManifestSectionsAreAligned(...)` checker in `R2RResultChecker`, driven by a plain `[Fact]` and a Windows-only `[ConditionalFact(IsWindows)]` `--pdb` variant that uses the same composite inputs. ## Validation Mirrors dotnet#129017: the `--pdb` variant emits an odd-sized `NativeDebugDirectoryEntryNode` that, without the fix, shifts the manifest sections off a 4-byte boundary; with the fix they are padded to a 4-byte RVA. Verified end-to-end by building an android-arm CoreCLR composite R2R APK with the fixed crossgen2 — R2RDump confirms `ManifestMetadata`, `ComponentAssemblies`, and `ManifestAssemblyMvids` all start on 4-byte-aligned RVAs — resolving the crash reported in dotnet/android#12026. cc @jtschuster (author of the sibling fix dotnet#129017) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.