Pre-RFC: Rust version of `__attribute(used)__` (GCC) or `llvm.used` (LLVM).

[dpc]

There come times when rust symbols are referenced only by external assembler, sometimes in not-trivial way. It seems rustc is eager to remove them (even making them public does not help).

In clang and gcc there are ways to prevent it: __attribute__((used)) and llvm.used

It seems there is currently no way to force rust to retain a symbol? Can it be added?

[dpc]

Please??? :D

[frehberg]

I need this feature as well. Is there any way to achieve this with latest rust-release? Do you know about #1459

[KalitaAlexey]

@frehberg Do you talk about function? You can use pub and it won't be removed.

[strega-nil]

@KalitaAlexey I don't believe statics are afforded the same protection.

[eddyb]

@ubsan Anything exported can't ever be removed, so all you have to do is make it reachable from outside the crate. I'm not sure, but #[no_mangle] is likely to force export.

[strega-nil]

@eddyb Then I'm not sure what the point of llvm.used is?

[eddyb]

@ubsan It probably works on internal/private items, to keep them alive despite them not being exported.

[strega-nil]

@eddyb ... weird.

[dpc]

I don't think people understand this topic fully.

First in embedded system, there are tricks, like creating an array of things, by just putting them in the same executable section. This symbols will not referenced anywhere explicitly. But they must keep being in the section.

Second it's not about symbols between crates/libraries. It's about LTO removing stuff during final linking optimization. These symbols are not referenced anywhere explicitly so optimizer can remove them. The code, at runtime will go from the start to the section to the end, read the memory in the given section and do something with all the symbols bytes there.

To be able to do that, the symbols need to be marked as used, otherwise LTO will remove them. That is the purpose of __attribute(used)__ (GCC) or llvm.used, and AFAIK, other tricks will not work.

[strega-nil]

@dpc Ah, 'k, that makes sense.

[eddyb]

@dpc You can't use noop volatile assembly capturing the address of the global?

[dpc]

@eddyb: Nothing will reference that noop volatile assembly and LTO will remove that, and then the thing it referenced. :)

[strega-nil]

@dpc I don't believe volatile assembly can be removed, although I may be wrong.

[dpc]

The volatile prevents moves of memory accesses between before and after the volatile, removal of the asm code itself (ensuring it's side effects will take place, even if it return values are not used), and makes sure it will not be duplicated (no more than one-time side effects) - at least that was the guarantee in C, IIRC, similiar guarantees of access to volatile variables . However having volatile asm does not prevent dead code elimination on LTO to just strip the whole function altogether when linkers thinks the code/data is just never reached.

[eddyb]

@dpc Whereas llvm.used will work even from dead code, or something?