-
Notifications
You must be signed in to change notification settings - Fork 13k
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
ld64.lld: error: relocation BRANCH26 is out of range: -165194492 is not in [-134217728, 134217727]; references _calloc #52767
Comments
I am able to repro, note I had to add |
@thevinster is this the same as what https://reviews.llvm.org/D116705 should fix? |
I patched that locally and it didn't fix this issue :( The error sounds like a thunk isn't getting created at all, which is strange. I imagine |
BTW, the testcase tarball expires next week, should I upload it somewhere else? |
Yup, I think that'd be helpful. CC @nico, who I think looked at the range extension thunk code recently. |
Here's the same testcase, which shouldn't expire until next year: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Fald_IyiRO-ljidFJwvZig/runs/0/artifacts/public/build/testcase.tar.zstd (I'll update the original comment with this url too) |
I noticed this also doesn't link with ld64:
|
This issue inspired me to finally implement better diagnostic info for LLD :) This is what I've got:
I noticed that all the problematic symbols were in a section called I wouldn't be surprised if ld64's implementation has a similar (wrong) assumption... |
…sage This makes it easier to debug those errors. See e.g. #52767 (comment) We take the approach of 'reverse-engineering' the InputSection from the output buffer offset. This provides for a cleaner Target API, and is similar to LLD-ELF's implementation of getErrorPlace(). Reviewed By: #lld-macho, Roger Differential Revision: https://reviews.llvm.org/D118903
We hit the same issue when we compile a large C++ project with Xcode, enable Asan/UBSan, and place some code in dedicated sections. |
@stheophil does ld64 link the same project successfully? |
No, ld64 is the Xcode linker right? So we use ld64 and it fails to link. |
…sage This makes it easier to debug those errors. See e.g. llvm/llvm-project#52767 (comment) We take the approach of 'reverse-engineering' the InputSection from the output buffer offset. This provides for a cleaner Target API, and is similar to LLD-ELF's implementation of getErrorPlace(). Reviewed By: #lld-macho, Roger Differential Revision: https://reviews.llvm.org/D118903
…sage This makes it easier to debug those errors. See e.g. llvm#52767 (comment) We take the approach of 'reverse-engineering' the InputSection from the output buffer offset. This provides for a cleaner Target API, and is similar to LLD-ELF's implementation of getErrorPlace(). Reviewed By: #lld-macho, Roger Differential Revision: https://reviews.llvm.org/D118903
Try 15.0.7 still has this kind problem. any way to work around ? |
i just came across this issue. has anyone found a workaround yet? |
Summary: This supersedes #87818 and fixes #52767 When calculating arm64 thunks, we make a few assumptions that may not hold when considering code sections outside of `__text`: 1. That a section needs thunks only if its size is larger than the branch range. 2. That any calls into `__stubs` are necessarily forward jumps (that is, the section with the jump is ordered before `__stubs`) Sections like this exist in the wild, most prominently the `__lcxx_overrides` section introduced in #69498 This change: - Ensures that if one section in `__TEXT` gets thunks, all of them do. - Makes all code sections in `__TEXT` contiguous (and guaranteed to be placed before `__stubs`) Test Plan: Reviewers: Subscribers: Tasks: Tags: Differential Revision: https://phabricator.intern.facebook.com/D60251191
Building Firefox for arm64 macos with disabled optimizations and with lld fails with:
STR:
tar --zstd -xf testcase.tar.zstd
cd testcase/toolkit/library/build
clang++ --sysroot /path/to/MacOSX11.0.sdk -F/path/to/MacOSX11.0.sdk/System/Library/PrivateFrameworks -mmacosx-version-min=11.0 -stdlib=libc++ --target=aarch64-apple-darwin -o XUL -Wl,-filelist,XUL.list -fuse-ld=lld -framework Cocoa -lobjc -framework AudioToolbox -lresolv ../../../security/nss/lib/crmf/crmf_crmf/libcrmf.a ../../../js/src/build/libjs_static.a ../../../aarch64-apple-darwin/debug/libgkrust.a ../../../security/libnss3.dylib ../../../config/external/lgpllibs/liblgpllibs.dylib ../../../mozglue/build/libmozglue.dylib -dynamiclib -lbsm -framework IOSurface -framework IOKit -framework AudioToolbox -framework CoreMedia -framework VideoToolbox -framework LocalAuthentication -framework Security -lm -framework OpenGL -framework SystemConfiguration -framework AVFoundation -framework CoreUI -framework CoreSymbolication -lcups -framework Foundation -framework CoreFoundation -framework CoreLocation -framework QuartzCore -framework Carbon -framework CoreAudio -framework CoreVideo -framework AudioToolbox -framework AudioUnit -framework AddressBook -framework OpenGL -framework Security -framework ServiceManagement -framework CoreServices -framework ApplicationServices -framework AppKit -weak_framework Metal -weak_framework MediaPlayer
Cc: @nico @int3 @keith
The text was updated successfully, but these errors were encountered: