-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
llvm-objcopy regression: Invalid iOS Mach-O: __TEXT segment fileoffset is not zero #130472
Milestone
Comments
This was referenced Mar 9, 2025
@llvm/issue-subscribers-tools-llvm-objcopy-strip Author: Tim Neumann (TimNN)
`llvm-objcopy good bad` on an iOS binary produces an output that it considered invalid by dyld.
This regressed in #120995, identified by Steps to reproduce (sorry, don't have a version without Rust): echo "fn main() {}" >> good.rs
# Rust version doesn't matter for this.
# Tested with the latest nightly & stable.
rustc --target=aarch64-apple-ios good.rs
llvm-objcopy good bad
# This is fine:
dyld_info good
# This fails:
dyld_info bad |
/cherry-pick 8413f4d |
/pull-request #131398 |
swift-ci
pushed a commit
to swiftlang/llvm-project
that referenced
this issue
Mar 17, 2025
…llvm#130517) Bug introduced llvm#120995. The LLD code calculates the "size" of the Mach-O headers, and then uses that size to place the segments, but the `__TEXT` section stays at `fileoff` zero. When I wrote the code into llvm-objcopy I calculated the extra space into the initial offset, which moved all the sections back 1 page. Besides the modified test checking for the right `fileoff` values of the sections and the segments, I also manually checked the generated binaries after `llvm-objcopy` using `dyld_info`, as the bug report suggested. Fixes llvm#130472 (cherry picked from commit 8413f4d)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
llvm-objcopy good bad
on an iOS binary produces an output that is considered invalid by dyld.dyld_info bad
fails with:This regressed in #120995, identified by
git bisect
and verified by reverting 1a830aa. cc @drodriguez (edit: See #120995 (comment) for what I believe that patch got wrong).Steps to reproduce (sorry, don't have a version without Rust):
The text was updated successfully, but these errors were encountered: