std: Fix thread_local! in non-PIE binaries #24448
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @pcwalton (rust_highfive has picked a reviewer for you, use r? to override) |
|
r? @huonw |
|
@bors r+ |
|
📌 Commit 4d9cc4a has been approved by |
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Apr 15, 2015
One of the parameters to the magical "register a thread-local destructor" function is called `__dso_handle` and largely just passed along (this seems to be what other implementations do). Currently we pass the *value* of this symbol, but apparently the correct piece of information to pass is the *address* of the symbol. In a PIE binary the symbol actually contains an address to itself which is why we've gotten away with what we're doing as long as we have. In a non-PIE binary the symbol contains the address `NULL`, causing a segfault in the runtime library if it keeps going. Closes rust-lang#24445
|
|
||
| struct Destroy; | ||
| impl Drop for Destroy { | ||
| fn drop(&mut self) { println!("drop"); } |
There was a problem hiding this comment.
This test might not reproduce this issue in the future, when/if println! does not depend on thread_local! anymore.
There was a problem hiding this comment.
Oh this was actually just here to help me debug it, it's triggered via the use of X instead of the contents of this destructor.
|
⌛ Testing commit 4d9cc4a with merge ae6f748... |
One of the parameters to the magical "register a thread-local destructor" function is called `__dso_handle` and largely just passed along (this seems to be what other implementations do). Currently we pass the *value* of this symbol, but apparently the correct piece of information to pass is the *address* of the symbol. In a PIE binary the symbol actually contains an address to itself which is why we've gotten away with what we're doing as long as we have. In a non-PIE binary the symbol contains the address `NULL`, causing a segfault in the runtime library if it keeps going. Closes rust-lang#24445
alexcrichton
force-pushed
the
issue-24445
branch
from
4d9cc4a to
3e57c6c
Compare
bors
added a commit
that referenced
this pull request
Apr 16, 2015
One of the parameters to the magical "register a thread-local destructor" function is called `__dso_handle` and largely just passed along (this seems to be what other implementations do). Currently we pass the *value* of this symbol, but apparently the correct piece of information to pass is the *address* of the symbol. In a PIE binary the symbol actually contains an address to itself which is why we've gotten away with what we're doing as long as we have. In a non-PIE binary the symbol contains the address `NULL`, causing a segfault in the runtime library if it keeps going. Closes #24445
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
One of the parameters to the magical "register a thread-local destructor"
function is called
__dso_handleand largely just passed along (this seems tobe what other implementations do). Currently we pass the value of this symbol,
but apparently the correct piece of information to pass is the address of the
symbol.
In a PIE binary the symbol actually contains an address to itself which is why
we've gotten away with what we're doing as long as we have. In a non-PIE binary
the symbol contains the address
NULL, causing a segfault in the runtimelibrary if it keeps going.
Closes #24445