Linking error with Xcode 15 invalid r_symbolnum #1456
Comments
|
The new linker indeed plays a role. With Xcode 15 it only reproduces when |
|
If someone with a mac is able to reproduce this and figure out to which function(s) these relocations which ld-prime complains about apply that would be very much appreciated. I don't have a mac myself, so I can't reproduce it locally. Note: arm64 macOS is not supported yet, so if you want to reproduce it on Apple Silicon you need to run the following to use the x86_64 toolchain in Rosetta 2: rustup toolchain install --force-non-host nightly-2024-03-30-x86_64-apple-darwin
rustup override set nightly-2024-03-30-x86_64-apple-darwin |
bjorn3
added
C-bug
|
GHA has started using an XCode version with ld-prime by default. Had to downgrade it in 05367c5. |
I get this errorI'll look into it more, but do you have any tips on how to get the information you need? |
|
I think the first step would be to try trimming down the crate it fails to link (in this case example/mini_core.rs) to try and narrow down which symbol it can't handle. |
|
Oh, I hadn't set the toolchain. Fixing that, I get this error: Looking in those object files, there's only one relocation for each of the r_symbolnum. Here's the relocations and associated symbols. Those symbols look wrong because they are in empty sections. |
If a data object is empty, that will create a symbol to an empty section. Looks like LLVM adds a dummy byte in that case. Is this required by Mach-O? |
How did you determine that? The symbols I gave above were for uses of
I don't know, but I don't understand how |
I created an static with a ZST as type: https://rust.godbolt.org/z/4f1f8eEj6
Anonymous allocations and statics are handled differently. Anonymous allocations get |
|
pub static FOO: &'static () = &();
pub static FOO: &'static str = "";Is this enough info to fix the problem? Here's a hack to diff --git a/src/write/mod.rs b/src/write/mod.rs
index 198ef5e..39cc988 100644
--- a/src/write/mod.rs
+++ b/src/write/mod.rs
@@ -488,9 +488,12 @@ impl<'a> Object<'a> {
&mut self,
symbol_id: SymbolId,
section: SectionId,
- data: &[u8],
+ mut data: &[u8],
align: u64,
) -> u64 {
+ if data.is_empty() {
+ data = &[0];
+ }
let offset = self.append_section_data(section, data, align);
self.set_symbol_data(symbol_id, section, offset, data.len() as u64);
offsetI'm not sure if this is the right place to fix this, and if it is we probably should only do this for symbols in Mach-O when using subsections. (Related to that, I notice cranelift never uses subsections for data, but for Mach-O |
In those cases the static contains a pointer to an anonymous allocation. Only the latter is zero sized.
Makes sense to me to do it there and in
That is because using subsections for data is not yet implemented: bytecodealliance/wasmtime#2368 |
|
There may be another bug somewhere. In https://bytecodealliance.zulipchat.com/#narrow/stream/217117-cranelift/topic/Minimal.20macos.20executable.20compilation someone hit a crash of the new linker in some code that directly uses cranelift-object without any empty data objects. |
|
With object 0.36 and cranelift 0.109 I'm now getting Edit: This is likely the same as bytecodealliance/wasmtime#8730 |
|
That job is for aarch64. It should be working for x86_64. |
|
Indeed, it works on x86_64: https://github.com/rust-lang/rustc_codegen_cranelift/actions/runs/9601537631/job/26492036864 |
|
3d54358 fixes the last known incompatibility with the new linker. |
Trying to run the cranelift testsuite on an x86_64 macOS system with Xcode 15 results in an error that looks roughly like this:
This is fairly easily reproducible, though it doesn't seem to happen 100% of the time. This is a blocker for rust-lang/rust updating the Xcode version.
Currently tested Xcode 15.0 and 15.2. A significant thing to note is that Xcode 15 introduced ld-prime, their new linker. One thing to consider while investigating is to try setting the linker flag
-ld_classicto narrow down if the new linker is a factor (sorry, I'm not familiar with cranelift's setup to help more).Tested at commit cdae185.
The text was updated successfully, but these errors were encountered: