intel_mac: make trailer format name-aware and support chaining#61
Open
nathanwhit wants to merge 1 commit into
Open
intel_mac: make trailer format name-aware and support chaining#61nathanwhit wants to merge 1 commit into
nathanwhit wants to merge 1 commit into
Conversation
The Intel-mac path appends a sentinel-terminated trailer to the end of the
binary, with `find_section` searching backward from EOF for the sentinel
and returning whatever data follows it. Before this change the trailer
stored only `[sentinel | data_len | data]` — no section name — so
`find_section` ignored its `section_name` argument and returned the most
recently appended data regardless of which name the caller asked for.
That breaks any binary that has more than one appended section. The
concrete failure case: a deno release binary has a `dnclbk` trailer
appended by the deno release pipeline; the user then runs `deno compile`,
which appends a `d3n0l4nd` trailer. Inside the produced binary,
`find_section("dnclbk")` would return the `d3n0l4nd` (last appended) data,
and the residual-lazy-source loader would then index a 1.3MB-shaped
manifest into a much smaller blob and panic.
Fix:
* New trailer layout (per section, chained at end of file):
sentinel 16 bytes '<~sui-data~>' (12) + magic (4)
name_len 1 byte u8
name name_len bytes (UTF-8, no NUL)
data_len 8 bytes u64 little-endian
data data_len bytes
* Two magic values are recognized: `MAGIC` (0xDEADC0DE) for the new
name-bearing format, `LEGACY_MAGIC` (0xEFBEADDE) for the older
name-less format (treated as matching only the empty name).
* `find_section(name)` walks backward across multiple trailers: if a
trailer's name doesn't match, scanning continues strictly before its
sentinel.
* `Macho::write_section` and `Macho::build` on x86_64 now carry the
section name through and emit it in the trailer.
* Added unit tests for chained sections and legacy-format fallback.
Existing tests pass unchanged.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #61 +/- ##
==========================================
+ Coverage 65.16% 69.95% +4.79%
==========================================
Files 3 3
Lines 864 942 +78
==========================================
+ Hits 563 659 +96
+ Misses 301 283 -18 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
littledivy
reviewed
May 20, 2026
littledivy
left a comment
Member
There was a problem hiding this comment.
Have you tested this on an intel mac? This code is fragile, ref #43
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.
The Intel-mac path appends a sentinel-terminated trailer to the end of the binary, with
find_sectionsearching backward from EOF for the sentinel and returning whatever data follows it. Before this change the trailer stored only[sentinel | data_len | data]— no section name — sofind_sectionignored itssection_nameargument and returned the most recently appended data regardless of which name the caller asked for.That breaks any binary that has more than one appended section. The concrete failure case: a deno release binary has a
dnclbktrailer appended by the deno release pipeline; the user then runsdeno compile, which appends ad3n0l4ndtrailer. Inside the produced binary,find_section("dnclbk")would return thed3n0l4nd(last appended) data, and the residual-lazy-source loader would then index a 1.3MB-shaped manifest into a much smaller blob and panic.Fix:
New trailer layout (per section, chained at end of file):
Two magic values are recognized:
MAGIC(0xDEADC0DE) for the new name-bearing format,LEGACY_MAGIC(0xEFBEADDE) for the older name-less format (treated as matching only the empty name).find_section(name)walks backward across multiple trailers: if a trailer's name doesn't match, scanning continues strictly before its sentinel.Macho::write_sectionandMacho::buildon x86_64 now carry the section name through and emit it in the trailer.Added unit tests for chained sections and legacy-format fallback.
Existing tests pass unchanged.