Stream: git-wasmtime

Topic: wasmtime / PR #13137 Allow passing Mach-O flags to `set_s...

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 12:14):

madsmtm opened PR #13137 from madsmtm:allow-macho-flags to bytecodealliance:main:

This enables rustc_codegen_cranelift to control these.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 12:14):

madsmtm requested cfallin for a review on PR #13137.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 12:14):

madsmtm requested wasmtime-compiler-reviewers for a review on PR #13137.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 12:14):

madsmtm edited PR #13137:

This enables rustc_codegen_cranelift to control these, see https://github.com/rust-lang/rustc_codegen_cranelift/pull/1648.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 12:16):

madsmtm submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 12:16):

madsmtm created PR review comment:

Another design for this could be to take:

segment: String,
section: String,
macho_section_type: String,
macho_section_attributes: Vec<String>,

And then have the "pure_instructions" -> S_ATTR_PURE_INSTRUCTIONS mapping in cranelift-object? What would you prefer?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 12:16):

madsmtm edited PR review comment.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 12:18):

bjorn3 submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 12:18):

bjorn3 created PR review comment:

Maybe directly use object::write::SectionFlags and then or those flags with the ones cranelift-object would set by default?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 12:22):

madsmtm submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 12:22):

madsmtm created PR review comment:

But that would introduce a dependency on object to cranelift-module?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 12:23):

bjorn3 submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 12:23):

bjorn3 created PR review comment:

Ah, right this is cranelift-module, not cranelift-object.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 15:54):

github-actions[bot] added the label cranelift on PR #13137.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 19 2026 at 15:54):

github-actions[bot] added the label cranelift:module on PR #13137.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 15:38):

cfallin added PR #13137 Allow passing Mach-O flags to set_segment_section to the merge queue

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 15:38):

cfallin submitted PR review:

Looks reasonable to me -- thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 15:59):

madsmtm submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 15:59):

madsmtm created PR review comment:

A third alternative would be:

custom_segment_section: Option<String>,

And do the entire parsing inside cranelift-object.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 17:40):

github-merge-queue[bot] removed PR #13137 Allow passing Mach-O flags to set_segment_section from the merge queue

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 17:48):

alexcrichton added PR #13137 Allow passing Mach-O flags to set_segment_section to the merge queue

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 19:00):

alexcrichton merged PR #13137.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 19:00):

alexcrichton removed PR #13137 Allow passing Mach-O flags to set_segment_section from the merge queue

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 19:58):

bjorn3 submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 19:58):

bjorn3 created PR review comment:

Actually shouldn't this be |=? As is this would overwrite the default flags even when no flags are passed.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 20:11):

madsmtm submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 20:11):

madsmtm created PR review comment:

I considered that, but there are no default flags for (SectionKind::Data, SectionKind::ReadOnlyData and SectionKind::ReadOnlyDataWithRel), and if there were, it would break if we tried to |= the section type.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 20:14):

bjorn3 submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 20:14):

bjorn3 created PR review comment:

Would skipping the flag set if macho_flags is 0 makes sense?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 20:14):

madsmtm submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 20:14):

madsmtm created PR review comment:

Maybe we could do:

let section_type = *macho_flags & SECTION_TYPE;
let section_attributes = *macho_flags & SECTION_ATTRIBUTES;
let current_attributes = (*flags & SECTION_ATTRIBUTES);
*flags = section_type | current_attributes | section_attributes;

But I feared that might be confusing too, if I request only no_dead_strip, it might be weird if I got other attributes too.

Though we should probably have an assert that *flags is 0.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 20:18):

madsmtm submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 20 2026 at 20:18):

madsmtm created PR review comment:

I opened https://github.com/bytecodealliance/wasmtime/pull/13153 for adding a debug assertion instead

Last updated: May 03 2026 at 22:13 UTC