Conversation
…tire the section-base heuristic + the vms-b14 exception)
The EVAX section-relative strong-over-weak override (vms-430) keyed on the
target section's BASE (offset 0) being an overridden weak, then added the
reloc addend. Two failure modes, both from keying on the section base rather
than the reloc's actual named target (base+addend = the referenced symbol's
own placed address):
(a) OVER-DRAG: when the offset-0 symbol was an overridden weak
(__malloc_allzerop in musl-alpha calloc.o/__libc_calloc.o), the base
redirect dragged every DISTINCT strong sibling sharing that $LINK$
section (decc$_calloc64 / __libc_calloc at +0x18) to strong+addend,
landing inside the wrong routine and a_crash()ing — patched by a
hardcoded __malloc_allzerop name exception (vms-b14).
(b) SILENT MISS: __libc_malloc_impl is WEAK at $LINK$ +0x30 in lite_malloc.o
(NOT offset 0) and STRONG in mallocng — the base-key redirect never
fired for it, leaving malloc split between mallocng and lite_malloc's
dead bump allocator: the two-allocator heap split that crashes the
small-alloc __malloc_donate path on the CRTL->RMS file-op veneer image
(vms-c5d, which blocks vms-3320 and the faithful endgame vms-fd1).
Root fix: redirect the EXACT named target (base+addend) via evax_wredir_apply,
shifting S by the weak->strong delta so the store's S+addend lands on the
strong def. An overridden weak at ANY section offset forwards to its strong
def; a distinct strong sibling's address is not a weak->strong key and is left
untouched. No section-base coincidence, no per-name exception, no .o alias
metadata — retires both the heuristic and the bounded vms-b14 exception.
Symbol-table evidence (musl-1.2.5-alpha objdump -t): the only overridden weaks
are __malloc_allzerop (off 0) and __libc_malloc_impl (off +0x30); every calloc/
malloc sibling that must be LEFT is a distinct strong (or sole-def weak) at a
nonzero offset, so exact-target keying separates them cleanly.
Host EVAX ctests green (run_evax_link/shareable/ximport/gvalfold/vmsrel/read).
Alpha proof (run_muldef_evax + crtl_rms3 boot, crash gone) on the rail.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013mZSxmiHPcUBuMNiVT5jXw
…e rail crtl_rms3 boot proof (do not reap; delete after)
…for the 3-heap-gate rail proof)
Contributor
Author
|
Closing — this proof-only PR did its job: it PROVED the vms-f59 linker redirect does NOT eliminate the crtl_rms3 crash (and regresses N=7). Superseded by re-scoping crtl_rms3 as a mallocng-on-alpha small-alloc bug. Do not merge. |
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
1 participant
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.
Draft, proof-only — DO NOT MERGE; closing after CI.
Runs CI's alpha CRTL→RMS file-op boot gate (
crtl_rms3) on the combined tree of the vms-f59 LINK.EXE fix (#1104) + the vms-3320 veneer (#1085), to prove the vms-f59 fix eliminates the__malloc_donatesmall-alloc SIGSEGV that vms-c5d flagged.Success = the alpha file-op veneer gate is green: no signal 11 on the first
creat, crtl_rms3 returns sentinel 7, and the independent ODS-2 DIRECTORY reader sees FOPCRE.DAT + FOPDST.DAT with real File IDs. This is the "prove the combined tree before landing vms-f59" gate.The real reap vehicles are #1104 (vms-f59) then #1085 (vms-3320, rebased on vms-f59). This PR is only to exercise the combined-tree gate that neither single-PR branch runs on its own.
🤖 Generated with Claude Code
https://claude.ai/code/session_013mZSxmiHPcUBuMNiVT5jXw