Add Mach-O section parsing#13869
Open
madsmtm wants to merge 1 commit into
Open
Conversation
Member
|
@bjorn3 would you be able to review this? |
madsmtm
force-pushed
the
parse-macho-section
branch
2 times, most recently
from
936f10a to
9853ed2
Compare
Mach-O sections have a type and a number of attributes, and are grouped in segments. There is a canonical textual representation that allows specifying this with the assembly .section directive (mostly defined by LLVM's source). Cranelift supported this with `DataDescription::custom_segment_section` by letting the user implement the parsing themselves, but this complicates the API (and will require breaking changes if we want to support specifying e.g. the stub size). Instead, `DataDescription::custom_section` is now just a `String`, and `cranelift-object` implements the parsing of the section name into its components. This is the same "layering" that LLVM has chosen, and it seems to work well there. This makes it easy for `rustc_cranelift_backend` to implement Rust's `#[link_section = ...]` to support things such as the `ctor` crate.
madsmtm
force-pushed
the
parse-macho-section
branch
from
9853ed2 to
ab3b658
Compare
Contributor
|
Sure. Will see if I can do that later today. |
madsmtm
commented
Jul 13, 2026
| binary_format: BinaryFormat, | ||
| ) -> Result<(&str, &str, u32), anyhow::Error> { | ||
| match binary_format { | ||
| // See https://github.com/llvm/llvm-project/blob/main/llvm/lib/MC/MCSectionMachO.cpp |
Contributor
Author
There was a problem hiding this comment.
LLVM's parsing is more lenient, they allow whitespace as well. I can implement that too if you want?
madsmtm
commented
Jul 13, 2026
| ("literal_pointers", S_LITERAL_POINTERS), | ||
| ("non_lazy_symbol_pointers", S_NON_LAZY_SYMBOL_POINTERS), | ||
| ("lazy_symbol_pointers", S_LAZY_SYMBOL_POINTERS), | ||
| // ("symbol_stubs", S_SYMBOL_STUBS) (requires extra param stub size) |
Contributor
Author
There was a problem hiding this comment.
This requires a stub size (5th part of the custom section name) that should be set with:
https://docs.rs/object/latest/object/read/macho/trait.Section.html#method.symbol_stub_size
I can implement that too it if you want me to?
github-actions
Bot
added
cranelift
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
3 participants
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 type and a number of attributes, and are grouped in segments. There is a canonical textual representation that allows specifying this with the assembly .section directive (mostly defined by LLVM's source).
Cranelift supported this with
DataDescription::custom_segment_sectionby letting the user implement the parsing themselves, but this complicates the API (and will require breaking changes if we want to support specifying e.g. the stub size).Instead,
DataDescription::custom_sectionis now just aString, andcranelift-objectimplements the parsing of the section name into its components. This is the same "layering" that LLVM has chosen, and it seems to work well there.This makes it easy for
rustc_cranelift_backendto implement Rust's#[link_section = ...]to support things such as thectorcrate.Discussed a bit in #13137, I changed my mind since then.
Fixes #8901.
Replaces rust-lang/rustc_codegen_cranelift#1648.