export_name with unusual utf8 breaks new version script based linker #38238
Comments
|
I guess, we should just restrict export_name to ASCII. cc @rust-lang/compiler |
|
So this is an artificial restriction, for no technical merit. I'd really like utf8 support for symbol names, just on principle. Nevertheless it doesn't work as is now (and used to) (albeit entirely because of a broken linker toolchain), so ASCII might be required... Iirc, swift re-encodes utf symbols in their name mangler, but that's not the same as real utf8 symbol names in the binary, which is just literally the coolest. I don't know of another language that allows that and can run (and the dynamic linker doesn't have any problem with it, because it just sees null terminated bytes, which utf8 preserves.) |
|
With which linkers do you run into the problem? |
|
Both gold and ld ( #[export_name="󠆷∀🢫"]
#[no_mangle]
pub extern fn whatever() {
println!("nothing");
}I guess unicode is too hard for C ppls. |
|
I think we should report this as a bug against GNU LD, unless there is a way to quote symbol names. |
Mark-Simulacrum
added
A-linkage
Mark-Simulacrum
added
the
C-feature-request
|
Triage: not aware of any changes |
|
Worth noting, this is not restricted to Unicode. Any non-alphanumeric characters like |
|
Why are you using spaces in the symbol names instead of something like |
|
Because then there is absolutely no ambiguity about what's an intended export of the wasm module vs random compiler (or user-written!) garbage, and because you can easily write it or interpret it by hand, and because we don't have to be portable when the only intended target is wasm32 and wasm32 supports it. It works on Mac, it works on Linux with rustc 1.2.0, but it doesn't work on Linux with current rustc. |
|
If you want to avoid ambiguity just add a random string to it. I did expect spaces to not work with GCC and when using an external assembler with LLVM (as rustc used to do for some targets due to LLVM missing an internal assembler for them) |
|
This needs to be fixed in linkers. |
|
It might worth a separate lint at the same time... I don't believe linker behavior will be tweaked at the near future. |
|
Why is a linker script needed? |
|
One can have a C function with a non-ASCII name, FYI. |
|
We are using a version script, not a linker script. This to tell the linker which symbols to export from the dylib/cdylib. |
Unfortunately it looks like the awesome changes in #38117 caused breakage while linking when a weird export name is used (probably due to the version script requiring ascii, or some other esoterica):
NOTE haven't checked this particular version, but certain combinations of values cause linker error complaining about invalid chars in version script.
The text was updated successfully, but these errors were encountered: