rustc: Support various flavors of linkages #12556

alexcrichton · 2014-02-26T00:49:44Z

It is often convenient to have forms of weak linkage or other various types of
linkage. Sadly, just using these flavors of linkage are not compatible with
Rust's typesystem and how it considers some pointers to be non-null.

As a compromise, this commit adds support for weak linkage to external symbols,
but it requires that this is only placed on extern statics of type *T.
Codegen-wise, we get translations like:

    // rust code
    extern {
        #[linkage = "extern_weak"]
        static foo: *i32;
    }

    // generated IR
    @foo = extern_weak global i32
    @_some_internal_symbol = internal global *i32 @foo

All references to the rust value of foo then reference _some_internal_symbol
instead of the symbol _foo itself. This allows us to guarantee that the
address of foo will never be null while the value may sometimes be null.

An example was implemented in std::rt::thread to determine if
__pthread_get_minstack() is available at runtime, and a test is checked in to
use it for a static value as well. Function pointers a little odd because you
still need to transmute the pointer value to a function pointer, but it's
thankfully better than not having this capability at all.

Thanks to @bnoordhuis for the original patch, most of this work is still his!

alexcrichton · 2014-02-26T00:50:57Z

cc #11978 (original implementation)

bharrisau · 2014-02-26T01:30:13Z

src/libstd/rt/thread.rs

+        type F = extern "C" unsafe fn(*libc::pthread_attr_t) -> libc::size_t;
+        extern {
+            #[linkage = "extern_weak"]
+            static __pthread_get_minstack: *u8;


I get that it is a pointer type/length anyway, but why the *u8 instead of *F?

fn() is a function pointer already, so *F would be a pointer to a function pointer. (And this is part of the reason that this change was necessary: function pointers are a slightly peculiar mix of pointer and value.)

@huonw's answer is spot on.

So the FFI tutorial should recommend that *u8 is used in this case? (I was thinking about writing up some docs for this when it lands and just want to know what the recommended practice is)

This is a gated feature because it is not supported on all platforms and I'm not sure that we'll want to stick with this interface forever. I wouldn't be opposed to docs, of course, though.

Any pointer would suffice here, it's essentially a "pointer to instructions" which varies per platform. I suppose a more proper type would be something like *() so you can't read it?

*() feels more special than rand(*u8, *i8, *u16, *i16, etc). ;)

bharrisau · 2014-02-26T01:38:12Z

Is it worth adding a WeakFn trait to std::ptr. Just copy the RawPtr but change the to_option to give an Option<T> instead of Option<&T>. impl it for *u8 (or *Any).

alexcrichton · 2014-02-26T02:16:09Z

Is it worth adding a WeakFn trait to std::ptr

Due to this being a gated feature, I don't think that's necessary at this time.

huonw · 2014-02-26T02:18:49Z

src/test/run-pass/linkage1.rs

+fn main() {
+    assert!(!foo.is_null());
+    assert_eq!(unsafe { *foo }, 3);
+    asset!(something_that_should_never_exist.is_null());


Neat macro, maybe it should take an argument that's the monetary value of the asset too?

(I think you're missing an r.)

bharrisau · 2014-03-06T00:36:25Z

Bors is close to getting bored. Is this waiting on anything?

alexcrichton · 2014-03-09T20:03:16Z

ping r?

flaper87 · 2014-03-09T20:15:01Z

src/test/compile-fail/linkage1.rs

@@ -0,0 +1,14 @@
+// Copyright 2014 The Rust Project Developers. See the COPYRIGHT


I'd prefer to have linkage[123].rs squashed in a single compile-fail test. Also, it would be nice to have a small description of what the test is doing.

Could the test file be renamed to linkage-weak ?

linkage1 must be standalone because it's testing the feature gate, and the other two could be combined, but there'll always be at least 2.

These are testing the linkage attribute, not just weak linkage, so linkage-weak is a bit deceptive.

+1 for not renaming, it'd be nice to have a comment and perhaps merge the other 2, though. I'd expect other linkage tests to be added there.

Ah, I remember now, an error is a span_fatal rather than a span_err, so that's why they're in separate files.

oh ok, then nevermind, 😄 (mind adding a comment?)

flaper87 · 2014-03-09T20:20:34Z

I just have a couple of nitpicky comments.

@foo

It is often convenient to have forms of weak linkage or other various types of linkage. Sadly, just using these flavors of linkage are not compatible with Rust's typesystem and how it considers some pointers to be non-null. As a compromise, this commit adds support for weak linkage to external symbols, but it requires that this is only placed on extern statics of type `*T`. Codegen-wise, we get translations like: // rust code extern { #[linkage = "extern_weak"] static foo: *i32; } // generated IR @foo = extern_weak global i32 @_some_internal_symbol = internal global *i32 @foo All references to the rust value of `foo` then reference `_some_internal_symbol` instead of the symbol `_foo` itself. This allows us to guarantee that the address of `foo` will never be null while the value may sometimes be null. An example was implemented in `std::rt::thread` to determine if `__pthread_get_minstack()` is available at runtime, and a test is checked in to use it for a static value as well. Function pointers a little odd because you still need to transmute the pointer value to a function pointer, but it's thankfully better than not having this capability at all.

@foo

It is often convenient to have forms of weak linkage or other various types of linkage. Sadly, just using these flavors of linkage are not compatible with Rust's typesystem and how it considers some pointers to be non-null. As a compromise, this commit adds support for weak linkage to external symbols, but it requires that this is only placed on extern statics of type `*T`. Codegen-wise, we get translations like: ```rust // rust code extern { #[linkage = "extern_weak"] static foo: *i32; } // generated IR @foo = extern_weak global i32 @_some_internal_symbol = internal global *i32 @foo ``` All references to the rust value of `foo` then reference `_some_internal_symbol` instead of the symbol `_foo` itself. This allows us to guarantee that the address of `foo` will never be null while the value may sometimes be null. An example was implemented in `std::rt::thread` to determine if `__pthread_get_minstack()` is available at runtime, and a test is checked in to use it for a static value as well. Function pointers a little odd because you still need to transmute the pointer value to a function pointer, but it's thankfully better than not having this capability at all. Thanks to @bnoordhuis for the original patch, most of this work is still his!

…t, r=Veykril fix: Support generics in extract_function assist This change attempts to resolve issue rust-lang#7636: Extract into Function does not create a generic function with constraints when extracting generic code. In `FunctionBody::analyze_container`, we now traverse the `ancestors` in search of `AnyHasGenericParams`, and attach any `GenericParamList`s and `WhereClause`s we find to the `ContainerInfo`. Later, in `format_function`, we collect all the `GenericParam`s and `WherePred`s from the container, and filter them to keep only types matching `TypeParam`s used within the newly extracted function body or param list. We can then include the new `GenericParamList` and `WhereClause` in the new function definition. This change only impacts `TypeParam`s. `LifetimeParam`s and `ConstParam`s are out of scope for this change. I've never contributed to this project before, but I did try to follow the style guide. I believe that this change represents an improvement over the status quo, but I think it's also fair to argue that it doesn't fully "fix" the linked issue. I'm totally open to merging this as is, or going further to try to make a more complete solution. Also: if there are other unit or integration tests I should add, please let me know where to look!

bharrisau reviewed Feb 26, 2014
View reviewed changes

huonw reviewed Feb 26, 2014
View reviewed changes

flaper87 reviewed Mar 9, 2014
View reviewed changes

flaper87 mentioned this pull request Mar 10, 2014

Android segfaults for API level <18 #9700

Closed

bors merged commit 699b33d into rust-lang:master Mar 11, 2014

alexcrichton deleted the weak-linkage branch March 12, 2014 04:16

jethrogb mentioned this pull request Feb 9, 2016

Specifying linkage on externs silently removes indirection #31508

Open

pnkfelix mentioned this pull request Sep 12, 2018

linkage weak_extern through generics breaks when -O absent on OS X #54153

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

rustc: Support various flavors of linkages #12556

rustc: Support various flavors of linkages #12556

alexcrichton commented Feb 26, 2014

alexcrichton commented Feb 26, 2014

bharrisau Feb 26, 2014

huonw Feb 26, 2014

alexcrichton Feb 26, 2014

bharrisau Feb 26, 2014

alexcrichton Feb 26, 2014

bharrisau Feb 26, 2014

bharrisau commented Feb 26, 2014

alexcrichton commented Feb 26, 2014

huonw Feb 26, 2014

bharrisau commented Mar 6, 2014

alexcrichton commented Mar 9, 2014

flaper87 Mar 9, 2014

alexcrichton Mar 9, 2014

flaper87 Mar 10, 2014

alexcrichton Mar 10, 2014

flaper87 Mar 10, 2014

flaper87 commented Mar 9, 2014

		@@ -0,0 +1,14 @@
		// Copyright 2014 The Rust Project Developers. See the COPYRIGHT

rustc: Support various flavors of linkages #12556

rustc: Support various flavors of linkages #12556

Conversation

alexcrichton commented Feb 26, 2014

alexcrichton commented Feb 26, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bharrisau commented Feb 26, 2014

alexcrichton commented Feb 26, 2014

Choose a reason for hiding this comment

bharrisau commented Mar 6, 2014

alexcrichton commented Mar 9, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

flaper87 commented Mar 9, 2014