Use decorated names for linked_symbols on Windows #96444
Conversation
rustbot
added
the
T-compiler
rust-highfive
added
the
S-waiting-on-review
|
|
||
| let x86 = match &target.arch[..] { | ||
| "x86" => true, | ||
| "x86_64" => false, |
There was a problem hiding this comment.
Looks like this case also always results in undecorated names.
There was a problem hiding this comment.
x86_64 code can still use "vectorcall" convention
There was a problem hiding this comment.
The linked MS doc says "Note that in a 64-bit environment, functions are not decorated.", apparently it applies to vectorcall too?
Raw-dylib didn't attempt to support vector call yet, so I don't know what is the correct behavior there.
There was a problem hiding this comment.
That's an inaccurate statement, it should rather say that functions are not decorated by default. Vector call is still a separate calling convention on x64 however, and is still decorated (https://docs.microsoft.com/en-us/cpp/cpp/vectorcall?view=msvc-170, https://godbolt.org/z/asdbdzePz)
There was a problem hiding this comment.
Vector call is still a separate calling convention on x64
Yeah, I was aware of that, but wasn't sure about the decoration.
Just checked it with Visual Studio's C compiler, and looks like it's indeed the only calling convention that is decorated on x64.
There was a problem hiding this comment.
There was a problem hiding this comment.
Ha, I didn't even know this stuff is in open source now.
| .iter() | ||
| .map(|abi| abi.layout.size.bytes().next_multiple_of(target.pointer_width as u64 / 8)) | ||
| .sum(); | ||
| format!("{prefix}{undecorated}{suffix}{args_in_bytes}") |
There was a problem hiding this comment.
I've seen this logic elsewhere, it's split into fn i686_decorated_name and fn i686_arg_list_size as a part of implementation of the raw-dylib feature.
Could you make sure these two implementations do the same thing?
fn i686_decorated_name, for example, adds or not adds underscore depending on the mingw flag.
(Ideally the code would be shared, but not necessarily in this PR.)
There was a problem hiding this comment.
I just checked that the current behaviour in i686_decorated_name to not add _ in MinGW is due to the fact that it uses dlltool to create a library, and i686 dlltool will automatically add _ to symbols if it does not start with @. For the generated object files we need to add _ ourselves.
There are no other behavioural differences.
petrochenkov
added
S-waiting-on-author
|
@bors r+ |
|
📌 Commit 4f9acb2 has been approved by |
bors
added
S-waiting-on-bors
Add `@feat.00` symbol to symbols.o for COFF Fix rust-lang#96498 This is based on top of rust-lang#96444. r? `@petrochenkov`
|
☀️ Test successful - checks-actions |
Add `@feat.00` symbol to symbols.o for COFF Fix rust-lang#96498 This is based on top of rust-lang#96444. r? ``@petrochenkov``
|
Finished benchmarking commit (5560c51): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
Fix #96423
r? @petrochenkov