Skip to content

rustc: fix linkage of internal static nodes. #5614

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

graydon
Copy link
Contributor

@graydon graydon commented Mar 29, 2013

re bug that @nikomatsakis was hitting: when you define a static (old: const) containing a & or &[] expression, it will create temporaries (the underlying pointee) by creating a throwaway symbol for each temporary, each with global linkage, and each named "const". LLVM will helpfully rename multiple copies of this throwaway symbol to "const1" and "const2" and so forth in the same library. But if you have 2 libraries -- say, libcore and librustc -- that both do this, the dynamic linker (at least on linux) will happily do horrible things like make the slice in one library point to the bytes of the vector from the other library. This is obviously a recipe for much hilarity and head-scratching.

The solution is to change the linkage to something else, internal or (in the case of this patch) private.

It will require a snapshot to integrate this into stage0 and thereby fix the problem / unblock patches that were hitting this in stage1.

@nikomatsakis
Copy link
Contributor

Oh dear. I wondered about that name const... nice catch.

bors added a commit that referenced this pull request Mar 29, 2013
re bug that @nikomatsakis was hitting: when you define a `static` (old: `const`) containing a `&` or `&[]` expression, it will create temporaries (the underlying pointee) by creating a throwaway symbol for each temporary, each with _global_ linkage, and each named `"const"`. LLVM will helpfully rename multiple copies of this throwaway symbol to `"const1"` and `"const2"` and so forth in the _same_ library. But if you have _2 libraries_ -- say, libcore and librustc -- that both do this, the dynamic linker (at least on linux) will happily do horrible things like make the slice in one library point to the bytes of the vector from the other library. This is obviously a recipe for much hilarity and head-scratching.

The solution is to change the linkage to something else, internal or (in the case of this patch) _private_.

It will require a snapshot to integrate this into stage0 and thereby fix the problem / unblock patches that were hitting this in stage1.
@bors bors closed this Mar 29, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request May 27, 2020
Test cargo lints

changelog: Add infrastructure to test cargo lints

Closes rust-lang#5603
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants