morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[PR #2342] [MERGED] fix(managed): classify 32-bit-preferred assemblies as platform neutral #5176

New issue

Closed

opened 2026-10-31 01:04:34 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:04:34 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/2342
Author: @huiq777
Created: 10/12/2026
Status: ✅ Merged
Merged: 10/13/2026
Merged by: @morluto

Base: main ← Head: fix/managed-prefer-32bit

📝 Commits (1)

29a674a fix(managed): classify 32-bit-preferred assemblies as platform neutral

📊 Changes

4 files changed (+47 additions, -5 deletions)

View changed files

📝 src/dotnet/ManagedArtifactInspector.test.ts (+24 -0)
📝 src/dotnet/ManagedArtifactInspector.ts (+4 -3)
📝 src/dotnet/ManagedNativeBoundaryHelpers.ts (+5 -2)
📝 src/dotnet/ManagedPeReader.ts (+14 -0)

📄 Description

Summary

A .NET assembly built as "AnyCPU, prefer 32-bit" is reported as x86-only. inspect_managed_artifact returns managed_architecture: "x86" and inspect_managed_native_boundaries returns cli_native.requires_32bit: true for an image the runtime treats as platform neutral.

No issue is linked: I found this while reading how the CLI header flags are interpreted, and it is an ordinary fix inside the existing static inspection.

Problem and expected behavior

Smallest trigger: a PE32 image with machine 0x014c whose CLI header Flags is 0x00020003 (ILONLY | 32BITREQUIRED | 32BITPREFERRED).

32BITREQUIRED (0x2) and 32BITPREFERRED (0x20000) are one two-bit field. dotnet/runtime src/coreclr/inc/corhdr.h says so directly:

In order to retain maximum backwards compatibility you cannot simply read or write one of these flags. You must treat them as a pair, a two-bit field with the following meanings:

32BITREQUIRED	32BITPREFERRED	Meaning in `corhdr.h`
0	0	no special meaning
0	1	illegal, reserved for future use
1	0	image is x86-specific
1	1	image is platform neutral and prefers to be loaded 32-bit when possible

The same header's COR_SET_32BIT_PREFERRED sets both bits, so a preferred image always has 0x2 set as well.

REA tested 0x2 first and on its own, so:

CLI flags	Before	After
`0x00000001`	`anycpu`, `requires_32bit: false`	unchanged
`0x00000003`	`x86`, `requires_32bit: true`	unchanged
`0x00020003`	`x86`, `requires_32bit: true`	`anycpu-prefer-32`, `requires_32bit: false`
`0x00020001` (reserved)	`anycpu-prefer-32`, `requires_32bit: false`	`anycpu`, `requires_32bit: false`

Before this change anycpu-prefer-32 was reachable only through the reserved combination, never through the one that means it.

Change and scope

managedCli32BitRequirement(flags) in src/dotnet/ManagedPeReader.ts, beside the ManagedCliHeader it reads, is now the one place that interprets the pair. It returns required, preferred or none, matching COR_IS_32BIT_REQUIRED and COR_IS_32BIT_PREFERRED.
managedArchitectureFor (ManagedArtifactInspector.ts) and cliNative (ManagedNativeBoundaryHelpers.ts) both use it instead of reading the bits separately.
The reserved combination now constrains nothing, which is how the runtime macros read it. pe.cli.flags and pe.cli.flag_names are untouched, so the source bits stay visible either way.

Not included: no schema, catalog or documentation change.

The two fields are derived differently, and that is unchanged:

managed_architecture uses the pair only for IL-only I386 images. Other machines and images without ILONLY keep returning the PE machine.
cli_native.requires_32bit is a projection of the header flags alone, with no machine or IL-only condition, on base as well (I386 with flags 0x0 is x86 and false there). It now follows COR_IS_32BIT_REQUIRED on every image.

So two patterns that are not meaningful prefer-32-bit images also change requires_32bit from true to false while managed_architecture stays as it was: 0x20002 on I386 (both bits without ILONLY, still x86) and 0x20003 on a non-I386 machine such as x64 (still x86_64). An earlier version of this description said other machines were unaffected; that was true of managed_architecture only. The measurements are in the comment below.

Follow the contribution scope.
Scope decision: not applicable. This is a fix to how existing header bytes are read.

Contract and boundary impact

Semantic owner and earliest changed stage: CLI header interpretation in src/dotnet/ManagedPeReader.ts; the two consumers above.
Contribution scope fit and linked maintainer decision: static format inspection within existing boundaries; not applicable.
CLI and MCP/tool-catalog contract: no schema change. The values of classification.managed_architecture and cli_native.requires_32bit change for images that set 32BITPREFERRED, as in the table above.
Provider, bridge, target-format, or platform compatibility: managed static provider only. managed_architecture changes for IL-only I386 images; requires_32bit changes for any image with both bits set.
Evidence, artifact, provenance, or reconstruction contract: none. Raw flags and flag_names are unchanged.
Target selection, authority, upstream behavior, and cleanup details (if applicable): not applicable.
Generated metadata (docs/public/product-catalog.json), package, or installation impact: none.

Expected effects (check known effects; use documentation-only on its own).
Unchecked items do not establish absence; leave uncertainties visible.

Read existing files or captured data.
Launch or attach to a process.
Inject instrumentation or run scripts/code.
Change process memory, registers, files, or configuration.
Contact network services.
Recover protected code or work around protections.
Documentation or usability only; no target interaction.
Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

Tests added or updated: one table test in src/dotnet/ManagedArtifactInspector.test.ts that runs all four combinations through inspectManagedArtifactBytes and inspectManagedNativeBoundariesBytes.
Base reproduction or other evidence (executed): without the fix the new test fails on two rows: 0x00020003 gives x86 where anycpu-prefer-32 is expected, and 0x00020001 gives anycpu-prefer-32 where anycpu is expected. The flag semantics are source-derived from corhdr.h, quoted above.

User-visible CLI/MCP output (executed, after the fix, on files written from buildManagedPeFixture):

rea inspect-managed-artifact Prefer32.dll
  pe.cli.flags 131075, flag_names [il-only, 32-bit-required, 32-bit-preferred]
  classification.managed_architecture  anycpu-prefer-32
rea inspect-managed-native-boundaries Prefer32.dll
  cli_native.requires_32bit  false

rea inspect-managed-artifact X86Only.dll
  pe.cli.flags 3, flag_names [il-only, 32-bit-required]
  classification.managed_architecture  x86
rea inspect-managed-native-boundaries X86Only.dll
  cli_native.requires_32bit  true

Remaining proof gaps: I did not have a .NET SDK on this host, so no compiler-produced prefer-32-bit assembly was inspected; the fixture sets the header flags directly.

For evidence-bearing changes:

Observed, derived, and inferred claims remain distinguishable.
Artifact identity, source provenance, and failed attempts remain preserved.
Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

macOS 15.6.1 arm64, Node 24.18.0, npm 11.16.0.

npm run test:local -- src/dotnet/ManagedArtifactInspector.test.ts src/dotnet/ManagedNativeBoundaryInspector.test.ts — 44 passed (rerun after rebasing onto fd95880)
npm run check:fast — passed (rerun after the rebase)
npx vitest run src/dotnet — 11 files, 187 tests passed
npm run test:focused -- tests/boundary/providers/managed/*.test.ts — 7 files, 45 tests passed
npm run check — passed
npm run verify:managed — verified: 11, including the dotnet-framework-x86-pinvoke scenario that pins flags 0x3 as x86

Not run: npm run check:pr and npm run docs:check (no contract or generated metadata changes).

Compatibility, safety, and release

Breaking changes or migration steps: none to schemas. A caller that read x86 or requires_32bit: true as "x86-only" will now see anycpu-prefer-32 and false for prefer-32-bit images, which is the correction.
Real Hopper/Ghidra, browser, or OS coverage: not applicable; no provider is involved.
Package or release metadata impact: none.
Security, privacy, process, or containment review: none; no new reads and no execution.

Before merge

This PR addresses a concrete problem or an agreed enhancement.
Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above.
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed.
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

AI assistance (Claude Code, model Claude Opus 5.5) was used for investigation, implementation and running the tests locally.

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/2342 **Author:** [@huiq777](https://github.com/huiq777) **Created:** 10/12/2026 **Status:** ✅ Merged **Merged:** 10/13/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/managed-prefer-32bit` --- ### 📝 Commits (1) - [`29a674a`](https://github.com/morluto/rea/commit/29a674ab68b1c96e6bf20bbd39b49dd7077591d2) fix(managed): classify 32-bit-preferred assemblies as platform neutral ### 📊 Changes **4 files changed** (+47 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `src/dotnet/ManagedArtifactInspector.test.ts` (+24 -0) 📝 `src/dotnet/ManagedArtifactInspector.ts` (+4 -3) 📝 `src/dotnet/ManagedNativeBoundaryHelpers.ts` (+5 -2) 📝 `src/dotnet/ManagedPeReader.ts` (+14 -0) </details> ### 📄 Description ## Summary A .NET assembly built as "AnyCPU, prefer 32-bit" is reported as x86-only. `inspect_managed_artifact` returns `managed_architecture: "x86"` and `inspect_managed_native_boundaries` returns `cli_native.requires_32bit: true` for an image the runtime treats as platform neutral. No issue is linked: I found this while reading how the CLI header flags are interpreted, and it is an ordinary fix inside the existing static inspection. ## Problem and expected behavior Smallest trigger: a PE32 image with machine `0x014c` whose CLI header `Flags` is `0x00020003` (`ILONLY | 32BITREQUIRED | 32BITPREFERRED`). `32BITREQUIRED` (`0x2`) and `32BITPREFERRED` (`0x20000`) are one two-bit field. dotnet/runtime [`src/coreclr/inc/corhdr.h`](https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/corhdr.h) says so directly: > In order to retain maximum backwards compatibility you cannot simply read or write one of these flags. You must treat them as a pair, a two-bit field with the following meanings: | 32BITREQUIRED | 32BITPREFERRED | Meaning in `corhdr.h` | | --- | --- | --- | | 0 | 0 | no special meaning | | 0 | 1 | illegal, reserved for future use | | 1 | 0 | image is x86-specific | | 1 | 1 | image is platform neutral and prefers to be loaded 32-bit when possible | The same header's `COR_SET_32BIT_PREFERRED` sets both bits, so a preferred image always has `0x2` set as well. REA tested `0x2` first and on its own, so: | CLI flags | Before | After | | --- | --- | --- | | `0x00000001` | `anycpu`, `requires_32bit: false` | unchanged | | `0x00000003` | `x86`, `requires_32bit: true` | unchanged | | `0x00020003` | `x86`, `requires_32bit: true` | `anycpu-prefer-32`, `requires_32bit: false` | | `0x00020001` (reserved) | `anycpu-prefer-32`, `requires_32bit: false` | `anycpu`, `requires_32bit: false` | Before this change `anycpu-prefer-32` was reachable only through the reserved combination, never through the one that means it. ## Change and scope - `managedCli32BitRequirement(flags)` in `src/dotnet/ManagedPeReader.ts`, beside the `ManagedCliHeader` it reads, is now the one place that interprets the pair. It returns `required`, `preferred` or `none`, matching `COR_IS_32BIT_REQUIRED` and `COR_IS_32BIT_PREFERRED`. - `managedArchitectureFor` (`ManagedArtifactInspector.ts`) and `cliNative` (`ManagedNativeBoundaryHelpers.ts`) both use it instead of reading the bits separately. - The reserved combination now constrains nothing, which is how the runtime macros read it. `pe.cli.flags` and `pe.cli.flag_names` are untouched, so the source bits stay visible either way. Not included: no schema, catalog or documentation change. The two fields are derived differently, and that is unchanged: - `managed_architecture` uses the pair only for IL-only I386 images. Other machines and images without `ILONLY` keep returning the PE machine. - `cli_native.requires_32bit` is a projection of the header flags alone, with no machine or IL-only condition, on base as well (I386 with flags `0x0` is `x86` and `false` there). It now follows `COR_IS_32BIT_REQUIRED` on every image. So two patterns that are not meaningful prefer-32-bit images also change `requires_32bit` from `true` to `false` while `managed_architecture` stays as it was: `0x20002` on I386 (both bits without `ILONLY`, still `x86`) and `0x20003` on a non-I386 machine such as x64 (still `x86_64`). An earlier version of this description said other machines were unaffected; that was true of `managed_architecture` only. The measurements are in the comment below. Follow the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope). Scope decision: not applicable. This is a fix to how existing header bytes are read. ## Contract and boundary impact - Semantic owner and earliest changed stage: CLI header interpretation in `src/dotnet/ManagedPeReader.ts`; the two consumers above. - Contribution scope fit and linked maintainer decision: static format inspection within existing boundaries; not applicable. - CLI and MCP/tool-catalog contract: no schema change. The values of `classification.managed_architecture` and `cli_native.requires_32bit` change for images that set `32BITPREFERRED`, as in the table above. - Provider, bridge, target-format, or platform compatibility: managed static provider only. `managed_architecture` changes for IL-only I386 images; `requires_32bit` changes for any image with both bits set. - Evidence, artifact, provenance, or reconstruction contract: none. Raw `flags` and `flag_names` are unchanged. - Target selection, authority, upstream behavior, and cleanup details (if applicable): not applicable. - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact: none. Expected effects (check known effects; use documentation-only on its own). Unchecked items do not establish absence; leave uncertainties visible. - [x] Read existing files or captured data. - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. ## Evidence and regression coverage - Tests added or updated: one table test in `src/dotnet/ManagedArtifactInspector.test.ts` that runs all four combinations through `inspectManagedArtifactBytes` and `inspectManagedNativeBoundariesBytes`. - Base reproduction or other evidence (executed): without the fix the new test fails on two rows: `0x00020003` gives `x86` where `anycpu-prefer-32` is expected, and `0x00020001` gives `anycpu-prefer-32` where `anycpu` is expected. The flag semantics are source-derived from `corhdr.h`, quoted above. - User-visible CLI/MCP output (executed, after the fix, on files written from `buildManagedPeFixture`): ```text rea inspect-managed-artifact Prefer32.dll pe.cli.flags 131075, flag_names [il-only, 32-bit-required, 32-bit-preferred] classification.managed_architecture anycpu-prefer-32 rea inspect-managed-native-boundaries Prefer32.dll cli_native.requires_32bit false rea inspect-managed-artifact X86Only.dll pe.cli.flags 3, flag_names [il-only, 32-bit-required] classification.managed_architecture x86 rea inspect-managed-native-boundaries X86Only.dll cli_native.requires_32bit true ``` - Remaining proof gaps: I did not have a .NET SDK on this host, so no compiler-produced prefer-32-bit assembly was inspected; the fixture sets the header flags directly. For evidence-bearing changes: - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed macOS 15.6.1 arm64, Node 24.18.0, npm 11.16.0. - `npm run test:local -- src/dotnet/ManagedArtifactInspector.test.ts src/dotnet/ManagedNativeBoundaryInspector.test.ts` — 44 passed (rerun after rebasing onto `fd95880`) - `npm run check:fast` — passed (rerun after the rebase) - `npx vitest run src/dotnet` — 11 files, 187 tests passed - `npm run test:focused -- tests/boundary/providers/managed/*.test.ts` — 7 files, 45 tests passed - `npm run check` — passed - `npm run verify:managed` — `verified: 11`, including the `dotnet-framework-x86-pinvoke` scenario that pins flags `0x3` as `x86` Not run: `npm run check:pr` and `npm run docs:check` (no contract or generated metadata changes). ## Compatibility, safety, and release - Breaking changes or migration steps: none to schemas. A caller that read `x86` or `requires_32bit: true` as "x86-only" will now see `anycpu-prefer-32` and `false` for prefer-32-bit images, which is the correction. - Real Hopper/Ghidra, browser, or OS coverage: not applicable; no provider is involved. - Package or release metadata impact: none. - Security, privacy, process, or containment review: none; no new reads and no execution. ## Before merge - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. AI assistance (Claude Code, model Claude Opus 5.5) was used for investigation, implementation and running the tests locally. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:04:34 +00:00

closed this issue
added the
pull-request
label

bsakaguchi referenced this issue

2026-11-01 21:43:14 +00:00

[PR #5210] [CLOSED] fix(objdump): scope debug-link warnings to DWARF inspections #6816

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#5176

No description provided.

Rows
Columns