Make unprefixed consistently override the system allocator

[madsmtm]

The goal is to move the various workarounds for this feature in rustc to the jemalloc-sys crate instead.

I'm not entirely sure of the history here, but it is possible this was not done in the past because #[used] used to not work in libraries? In any case, we should be able to do it now.

Note that due to rust-lang/rust#133491, #[used] in libraries still doesn't work on macOS.

I tried to write a test for this, but it's just a very platform-specific issue, and I found it hard to exercise properly. You should be able to test it in rustc with something like the following:

#[cfg(feature = "jemalloc")]
use tikv_jemalloc_sys as _;

#[cfg(feature = "jemalloc")]
#[cfg(target_vendor = "apple")]
#[used]
static USED_ZONE_REGISTER: unsafe extern "C" fn() = {
    extern "C" {
        fn _rjem_je_zone_register();
    }
    _rjem_je_zone_register
};

fn main() {
    rustc_driver::main()
}

[ti-chi-bot]

Welcome @madsmtm! It looks like this is your first PR to tikv/jemallocator 🎉

[BusyJay]

Any references on how these statics are processed?

[madsmtm]

There's the reference on #[used], and the equivalent Clang attribute and GCC attribute.

But these are somewhat vague, perhaps intentionally so as this is very much a linker concept? I don't really have a good reference on linkers, the best I can do is reference this piece of source code in rustc that talks about a workaround for static libs, and the following section from the manual page for ld64:

A static library (aka static archive) is a collection of .o files with a table of contents that lists the global symbols in the .o files. ld will only pull .o files out of a static library if needed to resolve some symbol reference. Unlike traditional linkers, ld will continually search a static library while linking.

(Note that Rust .rlibs are internally archives / static libraries, and so the rules for static libaries apply to them as well).

[madsmtm]

Or if you have more specific questions about how things work then I can try to answer them, to the best of my ability?

[BusyJay]

I see. How about adding a test to show it work as expected? You can add a dylib crate that allocs in the root directory and then add a test crate that links both the dylib and jemalloc-sys. If it works as expected the test shoud be able to use jemalloc's free to dealloc the pointer from dylib.