Parse and set Mach-O section type and attributes#1648
Draft
madsmtm wants to merge 1 commit into
Draft
Conversation
madsmtm
commented
Apr 19, 2026
This was referenced Apr 19, 2026
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Apr 20, 2026
…trs, r=bjorn3 Add a test for Mach-O `#[link_section]` API inherited from LLVM The format of the `#[link_section]` attribute is under-documented, but on Mach-O, I think it's roughly the following BNF: ``` LinkSection -> Segment `,` Section (`,` (SectionType (`,` (SectionAttributes)?)?)?)? Segment -> <0 to 16 bytes> Section -> <0 to 16 bytes> SectionType -> `regular` | `zerofill` | `cstring_literals` | `4byte_literals` | `8byte_literals` | `literal_pointers` | `non_lazy_symbol_pointers` | `lazy_symbol_pointers` | `symbol_stubs` | `mod_init_funcs` | `mod_term_funcs` | `coalesced` | `interposing` | `16byte_literals` | `thread_local_regular` | `thread_local_zerofill` | `thread_local_variables` | `thread_local_variable_pointers` | `thread_local_init_function_pointers` SectionAttributes -> SectionAttribute (`+` SectionAttribute)* SectionAttribute -> `pure_instructions` | `no_toc` | `strip_static_syms` | `no_dead_strip` | `live_support`, `self_modifying_code` | `debug` ``` This PR adds a small test for a little part of this. Once rust-lang#154429 is resolved, this should make it possible to test rust-lang/rustc_codegen_cranelift#1648 end-to-end. r? bjorn3
rust-timer
added a commit
to rust-lang/rust
that referenced
this pull request
Apr 20, 2026
Rollup merge of #155517 - madsmtm:test-macho-link-section-attrs, r=bjorn3 Add a test for Mach-O `#[link_section]` API inherited from LLVM The format of the `#[link_section]` attribute is under-documented, but on Mach-O, I think it's roughly the following BNF: ``` LinkSection -> Segment `,` Section (`,` (SectionType (`,` (SectionAttributes)?)?)?)? Segment -> <0 to 16 bytes> Section -> <0 to 16 bytes> SectionType -> `regular` | `zerofill` | `cstring_literals` | `4byte_literals` | `8byte_literals` | `literal_pointers` | `non_lazy_symbol_pointers` | `lazy_symbol_pointers` | `symbol_stubs` | `mod_init_funcs` | `mod_term_funcs` | `coalesced` | `interposing` | `16byte_literals` | `thread_local_regular` | `thread_local_zerofill` | `thread_local_variables` | `thread_local_variable_pointers` | `thread_local_init_function_pointers` SectionAttributes -> SectionAttribute (`+` SectionAttribute)* SectionAttribute -> `pure_instructions` | `no_toc` | `strip_static_syms` | `no_dead_strip` | `live_support`, `self_modifying_code` | `debug` ``` This PR adds a small test for a little part of this. Once #154429 is resolved, this should make it possible to test rust-lang/rustc_codegen_cranelift#1648 end-to-end. r? bjorn3
github-actions Bot
pushed a commit
to rust-lang/rustc-dev-guide
that referenced
this pull request
Apr 21, 2026
…orn3 Add a test for Mach-O `#[link_section]` API inherited from LLVM The format of the `#[link_section]` attribute is under-documented, but on Mach-O, I think it's roughly the following BNF: ``` LinkSection -> Segment `,` Section (`,` (SectionType (`,` (SectionAttributes)?)?)?)? Segment -> <0 to 16 bytes> Section -> <0 to 16 bytes> SectionType -> `regular` | `zerofill` | `cstring_literals` | `4byte_literals` | `8byte_literals` | `literal_pointers` | `non_lazy_symbol_pointers` | `lazy_symbol_pointers` | `symbol_stubs` | `mod_init_funcs` | `mod_term_funcs` | `coalesced` | `interposing` | `16byte_literals` | `thread_local_regular` | `thread_local_zerofill` | `thread_local_variables` | `thread_local_variable_pointers` | `thread_local_init_function_pointers` SectionAttributes -> SectionAttribute (`+` SectionAttribute)* SectionAttribute -> `pure_instructions` | `no_toc` | `strip_static_syms` | `no_dead_strip` | `live_support`, `self_modifying_code` | `debug` ``` This PR adds a small test for a little part of this. Once rust-lang/rust#154429 is resolved, this should make it possible to test rust-lang/rustc_codegen_cranelift#1648 end-to-end. r? bjorn3
This comment has been minimized.
This comment has been minimized.
bjorn3
reviewed
May 24, 2026
Member
|
I updated Cranelift earlier today, so it should work after a rebase. |
Member
|
@madsmtm did you intend to work on this further or do you want me to pick it up? |
2783559 to
9230b1a
Compare
Contributor
Author
|
I've opened bytecodealliance/wasmtime#13869 instead, since on further reflection I think it makes more sense to have the parsing in |
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.
Mach-O sections have a 32-bit "flags" parameter, which contains 8 bits for a "section type", and 24 bits for "attributes". These can be controlled with
#[link_section = ...]like so:The default section type is "regular" (
S_REGULAR).This PR parses the section type names and attribute names understood by LLVM, and convert them to the corresponding Mach-O flags.
Fixes #1588.
Fixes bevyengine/bevy#20785.
Depends on bytecodealliance/wasmtime#13137.
Related to rust-lang/rust#155065, we could also put this parsing logic higher up, to rely less on LLVM / get diagnostics with spans for this on all backends?