Skip to content

intel_mac: make trailer format name-aware and support chaining#61

Open
nathanwhit wants to merge 1 commit into
mainfrom
intel-mac-name-aware-sections
Open

intel_mac: make trailer format name-aware and support chaining#61
nathanwhit wants to merge 1 commit into
mainfrom
intel-mac-name-aware-sections

Conversation

@nathanwhit

Copy link
Copy Markdown
Member

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.

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-commenter

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 77.14286% with 32 lines in your changes missing coverage. Please review.
✅ Project coverage is 69.95%. Comparing base (92f691a) to head (562412b).

Files with missing lines Patch % Lines
intel_mac.rs 75.57% 32 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@littledivy littledivy left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you tested this on an intel mac? This code is fragile, ref #43

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants