Skip to content

[rust][RelLookupTableConverter] Remove unnamed_addr on x86_64-apple-darwin #181

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

Conversation

dianqk
Copy link
Member

@dianqk dianqk commented May 12, 2025

Temporary fixes rust-lang/rust#140686.
I'm not sure if this is suitable for upstream, so I'd rather Apple address it in the next release.

…-darwin

I'm not sure if this is suitable for upstream,
so I'd rather Apple address it in the next release.
@cuviper
Copy link
Member

cuviper commented May 12, 2025

Is this something we could avoid on the Rust side instead? e.g. don't add that attribute in the first place? It would be a hack either way, but I think lower maintenance overhead if we change "our" code.

@dianqk
Copy link
Member Author

dianqk commented May 12, 2025

Is this something we could avoid on the Rust side instead? e.g. don't add that attribute in the first place? It would be a hack either way, but I think lower maintenance overhead if we change "our" code.

No :\
These global variables result from LLVM's transformation of switch statements into lookup tables.

@dianqk
Copy link
Member Author

dianqk commented May 14, 2025

As per rust-lang/rust#140686 (comment) , Apple is not planning a fix.

@dianqk dianqk closed this May 14, 2025
@dianqk dianqk deleted the rustc/20.1-2025-02-13-darwin-relookup branch May 14, 2025 00:31
@madsmtm
Copy link

madsmtm commented May 22, 2025

I know that Apple isn't planning to fix it, but maybe we should fix it anyhow?

@dianqk
Copy link
Member Author

dianqk commented May 22, 2025

I know that Apple isn't planning to fix it, but maybe we should fix it anyhow?

I can't be sure if this workaround will reliably support for the next five years (or longer), as I haven't debugged ld64 to find the root cause. I'm not sure if we should be supporting an end-of-life tool. Free to mention this issue at the compiler meetings. I can maintain this patch, but I don't know about the long-term direction. Perhaps someone could take over the maintenance of ld64, but who would review their changes?

@madsmtm
Copy link

madsmtm commented May 22, 2025

Fair enough

@dianqk
Copy link
Member Author

dianqk commented Jun 5, 2025

I know that Apple isn't planning to fix it, but maybe we should fix it anyhow?

@madsmtm FYI, this has been sent to upstream via llvm#142304. (You've probably already seen it.)

@madsmtm
Copy link

madsmtm commented Jun 5, 2025

Yeah, I did, thanks a lot!

basvandijk added a commit to dfinity/ic that referenced this pull request Jun 10, 2025
This reverts
c458123
which reverted the upgrade to rust-1.86.0.

The upgrade to rust-1.86.0 in
d1dc4c2
was initially reverted since it caused the
`//rs/pocket_ic_server:...` and `//packages/pocket-ic:...` tests to fail
on x86_64-apple-darwin.

We have now debugged this failure and it turns out this is due to a bug
in the apple linker that causes bad code to be generated for the `hyper`
HTTP client crate used in both the pocket-ic library and server. (Full
context
[here](rust-lang/rust#140686 (comment))).
LLVM has a
[workaround](rust-lang/llvm-project#181) that
they merged and rustc will integrate it soon.

Until then, it appears that the bug is only triggered when building with
the default `opt-level=2`. Until we’ve upgraded to the newest rustc (for
which we’ll need to wait for a new rules_rust version) we will build the
`hyper` crate with `opt-level=0`(I tried `opt-level=1` but that results
in the same failure).

This rust upgrade should also fix the non-reproducibility of the
`archive_canister_u256` and related canisters.

---------

Co-authored-by: IDX GitHub Automation <>
Co-authored-by: Martin Raszyk <martin.raszyk@dfinity.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants