Skip to content
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 name mangling workaround \x01 seems broken #110294

Open
MauriceKayser opened this issue Apr 13, 2023 · 5 comments
Open

LLVM name mangling workaround \x01 seems broken #110294

MauriceKayser opened this issue Apr 13, 2023 · 5 comments
Labels
A-linkage Area: linking into static, shared libraries and binaries A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. O-windows Operating system: Windows P-low Low priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@MauriceKayser
Copy link

I think #96444 might have broken the #[export_name = "\x01..."] LLVM workaround for avoiding the "@xyz" name mangling on x86. Compiling the following with i686-pc-windows-msvc results in error LNK2001: unresolved external symbol _☺test1@0:

#[export_name = "\x02test2"]
extern "stdcall" fn test2() {}

#[export_name = "\x01test1"]
extern "stdcall" fn test1() {}

I stumbled upon this when trying to use the \x01 workaround to specify the _aulldiv symbol, which the MSVC linker expects to be named __aulldiv (instead of __aulldiv@16) in #![no_std] x86 Windows crates.

@MauriceKayser MauriceKayser added C-bug Category: This is a bug. regression-untriaged Untriaged performance or correctness regression. labels Apr 13, 2023
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Apr 13, 2023
@MauriceKayser MauriceKayser changed the title LLVM name mangling bypass \x01 seems broken LLVM name mangling workaround \x01 seems broken Apr 13, 2023
@nbdd0121
Copy link
Contributor

Yeah, my PR indeed doesn't special case \x01. I believe the \x01 thing is a special LLVM-specific hack and was never the proper solution. We probably want a proper solution to turn off symbol decoration in Windows.

@nbdd0121
Copy link
Contributor

Are you trying to define or reference that symbol? You can use asm to workaround the issue.

@MauriceKayser
Copy link
Author

We probably want a proper solution to turn off symbol decoration in Windows.

Agreed, there are other issues with the export_name / no_mangle architecture on Windows as well, like #67399.

Are you trying to define or reference that symbol? You can use asm to workaround the issue.

I am trying to get rid of the naked_functions feature in my crates (1, 2), by porting the naked assembly functions to Rust code. The naked function does not care about the calling convention, but the Rust implementation does.

@nbdd0121
Copy link
Contributor

If you are getting rid of naked functions to remove nightly dependency, then you can switch to global_asm. If you are trying to reimplement the function in Rust, then what you could do is to add a global_asm! stub that jumps to the Rust implementation.

@jyn514 jyn514 added A-linkage Area: linking into static, shared libraries and binaries A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. O-windows Operating system: Windows regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed regression-untriaged Untriaged performance or correctness regression. labels Apr 14, 2023
@apiraino
Copy link
Contributor

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-low

@rustbot rustbot added P-low Low priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Apr 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. O-windows Operating system: Windows P-low Low priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants
@nbdd0121 @apiraino @jyn514 @MauriceKayser @rustbot and others