Tracking issue for the linkage feature

Tracks stabilization for the linkage attribute.

Note that this has peculiar semantics, see #156468.
In particular, unlike normal statics, the local global variable we generate for this indirection does not have a globally unique address (rust-lang/miri#5015, #156467).

@alexcrichton

cc @alexcrichton

Currently this translates to the various linkage models of LLVM, for example the values of the attribute can be:

match name {                                                         
    "appending" => Some(llvm::AppendingLinkage),                     
    "available_externally" => Some(llvm::AvailableExternallyLinkage),
    "common" => Some(llvm::CommonLinkage),                           
    "extern_weak" => Some(llvm::ExternalWeakLinkage),                
    "external" => Some(llvm::ExternalLinkage),                       
    "internal" => Some(llvm::InternalLinkage),                       
    "linkonce" => Some(llvm::LinkOnceAnyLinkage),                    
    "linkonce_odr" => Some(llvm::LinkOnceODRLinkage),                
    "private" => Some(llvm::PrivateLinkage),                         
    "weak" => Some(llvm::WeakAnyLinkage),                            
    "weak_odr" => Some(llvm::WeakODRLinkage),                        
    _ => None,                                                       
}

Some worries about this are:

These are very LLVM specific, it's unclear how applicable they are to other backends.
Beyond external or weak, I've never seen a reason to use the other attributes.
These linkage methods are platform-specific and aren't guaranteed to work everywhere.

That being said, it's the only way to do weak symbols on Linux and it's also convenient for exporting a known symbol without worrying about privacy on the Rust side of things. I would personally want to reduce the set of accepted linkage types and then state "well of course linkage is platform-specific!"

cc #29629

This feature is fundamentally broken. Consider the following code:

static unsigned long B = 0;
unsigned long *A = &B;
void f(void) { }

#![feature(linkage)]

#[link_name = "c_part"]
extern {
    #[linkage = "extern_weak"] static A: *const usize;
    fn f();
}

fn main() {
    unsafe {
        f();
        println!("{:x} @ {:x} @ {:p}", *(*A as *const usize), *A, A);
    }
}

Which prints 0 @ 5617765adaa8 @ 0x5617765ad890 meaning that the A seen by the rust code contains the address of A and not A itself. It's also easy to get LLVM to abort with this.

This attribute is also used incorrectly here.

#18804 needs to be resolved before stabilization.

I think we should at least work on stabilising the weak and extern_weak linkage. Both are very useful and a fairly widespread linkage options that seem to be supported (unlike many other options currently exposed) by at least all of the tier 1 targets.

To give an example of a use-case for weak linkage in Rust code (^{I need weak linkage for libloading}), one would be for global statics unique even between multiple versions of the same crate. Consider that, currently, if a binary links log = ^0.3 and log = ^0.4 some way, or another, it will end up having two distinct global loggers. This could trivially be resolved with some use of the weak linkage option (as it ensures – at link time – only one instance of global with the same name).

That being said, #[linkage] should always infect whatever it applies to with unsafety. Consider for example these two crates:

// crate older version
#[linkage="weak"]
static mut FOO: u32 = !0;

// crate newer version
#[linkage="weak"]
static mut FOO: char = 'a';

when linked together, all uses of FOO as seen from the newer-version crate would be UB if the linker happened to choose to link-in the value from the older version. This is functionally a transmute without size checks.

extern_weak is broken in such a dubious way that even though I pointed out two years ago that it was being used incorrectly in the stdlib, the bug still hasn't been fixed.

~$ cat strong.rs 
extern {
    static __progname: *const u8;
}

fn main() {
    unsafe {
        println!("  __progname:\t\t{:?}", __progname);
        println!(" &__progname:\t\t{:?}", &__progname as *const _);
        if !__progname.is_null() {
            println!(" *__progname:\t\t{:?}", *__progname as char);
        }
    }
}
~$ cat weak.rs 
#![feature(linkage)]

extern {
    #[linkage = "extern_weak"]
    static __progname: *mut *const u8;
}

fn main() {
    unsafe {
        println!("  __progname:\t\t{:?}", __progname);
        println!(" &__progname:\t\t{:?}", &__progname as *const _);
        if !__progname.is_null() {
            println!(" *__progname:\t\t{:?}", *__progname);
            if !(*__progname).is_null() {
                println!("**__progname:\t\t{:?}", **__progname as char);
            }
        }
    }
}
~$ rustc strong.rs 
~$ rustc weak.rs 
~$ ./strong 
  __progname:		0x7ffdfc7438ac
 &__progname:		0x7f10560a5360
 *__progname:		's'
~$ ./weak 
  __progname:		0x7f730b21f360
 &__progname:		0x5574a33bb008
 *__progname:		0x7fffe4ca38b2
**__progname:		'w'

gcc and clang handle this attribute correctly.

PS: The address of __dso_handle isn't actually too significant in __cxa_thread_atexit_impl and &__dso_handle is only a few bytes off.

PSS: Wow, looks like I already explained this above (also two years ago). Maybe the NSA is trying to keep this potential remote code execution unfixed. 🤔

Rollup merge of rust-lang#163405 - bjorn3:less_linkage_options, r=lqd

Link to Zulip discussion #general > Question(s) about making an RFC

Rollup merge of rust-lang#163405 - bjorn3:less_linkage_options, r=lqd

Unrolled build for #163405 in rollup 163609

Rollup merge of #163405 - bjorn3:less_linkage_options, r=lqd

Navigation Menu

Repository navigation

Tracking issue for the `linkage` feature #29603

38 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for the linkage feature #29603

Description

Activity

aturon commented on Nov 5, 2015

alexcrichton commented on Nov 5, 2015

aturon commented on Nov 5, 2015

mahkoh commented on Jan 11, 2016

mahkoh commented on Jan 11, 2016

brson commented on Jun 1, 2017

nagisa commented on Jan 6, 2018

mahkoh commented on Jan 13, 2018

38 remaining items

tgross35 commented on Sep 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking issue for the `linkage` feature #29603