Moving a PT_LOAD to the end of the file sets its p_align to
min(p_align, 0x1000), since the copy honours only the page. When that
segment carried the largest p_align, the output's largest PT_LOAD
alignment, which Linux uses to align the ET_DYN load bias, fell with
it. SeparateSharedLoadPages now returns the largest power-of-two
p_align above the page that it lowered, and WriteLayout aligns the
header block PT_LOAD to at least that value, as it already does for
the largest kept p_align.
Review feedback: the three mount-family patterns now carry their exact numbers (21, 378, 22) like the mman patterns, so a stub with another number is not matched. The fixture check that changed only the masked bytes could not fail for the unmount fixture, whose number is also 22; it now rewrites the number field to 0, 1, 21, 22 and 378 and requires every other number to be rejected. Technical debt says the numbers are pinned.
Recognize the inlined __syscall6 wrappers of ps5-payload-dev SDK libc/mount.c (mount, nmount, unmount) under --trap-sdk-syscall-stubs, with the four-byte syscall number immediate masked so an SDK build that renumbers the call still matches. The three wrappers differ in argument preparation, so each sequence is matched separately.
Observed in ftpsrv v0.21.1 (0x709a, 0x70ec, 0x713c) and websrv v0.35 (0xae6a, 0xaebc, 0xaf0c). Related: issue #8624, open draft PR #8729 covers mount only.
Addresses the #12591 review. Because the Windows image ORs page permissions,
refuse a congruent overlap when one segment is executable and the other
writable and the later segment does not start on a page boundary, which would
otherwise share a read-write-execute page; the rule is applied on both loaders
so their acceptance decision matches. Bound the congruence check to the
file-backed part of the overlap and compare spans rather than walking the
implicit zero bytes of a large bss overlap.
Expand test_executable_segments.py: byte-congruent tail and bss overlaps
accepted with their trimmed sizes and no output overlap; a write-execute
overlap refused at an unaligned boundary and accepted at an aligned one with
the Windows image carrying no write-execute section; differing bytes, an
overlap past the later end, a non-zero file byte over the later segment's bss,
and a shared start address refused; and a no-overlap control. Keep only the
PPSA ids in the relinker.md note.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Some homebrew toolchains emit an eboot whose read-only PT_LOAD runs over the
GNU_RELRO start of the following read-write PT_LOAD, with byte-identical content
over the overlap. The relinker refused every such title with "Overlapping
PT_LOAD memory ranges" on both the Linux and Windows paths (Photo Splat VR
PPSA99770 #12183, FoxHollow PPSA99573, WWE 13 PPSA92013).
When an earlier PT_LOAD's tail overlaps a later one, the overlapping bytes are
identical, and the overlap does not extend past the later segment, trim the
earlier segment to end where the later one starts so the later segment owns the
shared range. On Linux the preserved PT_GNU_RELRO makes that range read-only
after relocation, matching the earlier read-only mapping; the Windows image
builder has no RELRO step, so the shared range stays writable (noted in
docs/dev/debt/relinker.md).
Overlaps whose bytes differ (the #10564 case), that extend past the later
segment, or that share a start address with it are still refused on every
target; the last case would otherwise trim the earlier segment to zero length.
test_executable_segments.py covers the accepted tail overlap and all three
refused cases.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Family fallback entries appended for kernel-variant imports were marked
imported, so the startup stub hard-required every family member; a
partial libs/ without the unused sibling aborted with a load failure.
Track fallback positions separately so only the declared module and
canonical libkernel.prx stay required while siblings probe and skip.
Adds missing-sibling cases pinning expected providers (11 for the
declared variant, 22 for canonical libkernel.prx) and trims the debt
entry below the 1000-character limit.
Generated with [Devin](https://devin.ai)
Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
The debt entry on pointer fixups in executable segments claimed that
dyld refuses them, which no run had shown. It now states what was
measured on an M1 Pro running macOS 27.0.1 under Rosetta 2: dyld_info
reports both cases, the PF_R|PF_W|PF_X case loads and runs, and a
fixup into a PF_R|PF_X segment ends with SIGBUS in dyld. The
interpreter_in_code fixture keeps a read-only data PT_LOAD for the
Windows runs, so PE output still covers a RELATIVE into it.
The macOS image writer emitted dyld rebase and bind opcodes for any
target inside a segment, so an R_X86_64_RELATIVE into an R-X PT_LOAD
became a rebase into a read-execute segment. dyld-1378 refuses fixups
in segments without write access (enforceFixupsInWritableSegments), so
Locate now throws when the target segment lacks VM_PROT_WRITE. Such
inputs now fail the macOS conversion instead of writing an output that
dyld would not load.
In a leaf without a frame pointer, --frame-red-zone lowers RSP after
the prologue and adds the shift to every RSP operand in the body,
assuming RSP does not move between the prologue and the exits. It
refused explicit RSP arithmetic but not opcode-encoded pushes and pops,
so after "push rax" in the body the read of the pushed slot at [rsp]
became [rsp+0x10], a red-zone slot, and "pushfq; and qword [rsp], -2;
popfq" changed that slot instead of the saved flags. Such a leaf now
keeps its red zone and is reported as "push or pop inside the body":
push and pop of a register, push imm, push r/m, pop r/m, pushf, popf
and push or pop of fs or gs outside the exits. The pops of an exit
still frame, and leaves with a frame pointer, whose RSP operands are
already refused, still frame when they push and pop.
The entry for the M5 running macOS 26.4 did not say what Rosetta does
with SHA or AVX-512, and the XSAVE entry was measured only on macOS
27.0.1. On that host sha1rnds4 and a 256-bit-wide vpaddd on zmm raise an
illegal instruction alongside RDSEED, CLWB, RDPID, ADCX and ADOX, while
XSAVE writes an XSTATE_BV of 0x7 and XGETBV returns the same x87, SSE
and AVX mask although CPUID leaf 1 still reports neither XSAVE nor
OSXSAVE.
The BMI1 and BMI2 results were compared with the Intel SDM definitions
over 200,000 random inputs each for PDEP, PEXT, BEXTR, BZHI, LZCNT and
TZCNT, so the entry can say they compute the documented result rather
than only that they avoid a fault.
Dean