Skip to content
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

Tracking Issue for -C export-executable-symbols #84161

Open
1 of 3 tasks
nikomatsakis opened this issue Apr 13, 2021 · 8 comments · Fixed by #85673
Open
1 of 3 tasks

Tracking Issue for -C export-executable-symbols #84161

nikomatsakis opened this issue Apr 13, 2021 · 8 comments · Fixed by #85673
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC F-export_executable_symbols `#![feature(export_executable_symbols)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Apr 13, 2021

This is a tracking issue for the RFC "2841" (rust-lang/rfcs#2841).
The feature gate for the issue is #![feature(export_executable_symbols)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Unresolved Questions

  • Is this a good name for it?
  • Should it be more general and export when limit_rdylib_exports or crate_type == ProcMacro?

Implementation history

@nikomatsakis nikomatsakis added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC labels Apr 13, 2021
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Mar 24, 2022
RFC-2841: add codegen flag export symbols from executable

Closes rust-lang#84161
r? ``@nikomatsakis`` ``@Mark-Simulacrum``
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Mar 24, 2022
RFC-2841: add codegen flag export symbols from executable

Closes rust-lang#84161
r? ```@nikomatsakis``` ```@Mark-Simulacrum```
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jun 21, 2022
RFC-2841: add codegen flag export symbols from executable

Closes rust-lang#84161
r? ``@nikomatsakis`` ``@Mark-Simulacrum``
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jun 25, 2022
RFC-2841: add codegen flag export symbols from executable

Closes rust-lang#84161
r? `@nikomatsakis` `@Mark-Simulacrum`
@bors bors closed this as completed in dc2d232 Jul 25, 2022
@nagisa
Copy link
Member

nagisa commented Aug 1, 2022

This should not have been closed.

@nagisa nagisa reopened this Aug 1, 2022
@bjorn3
Copy link
Member

bjorn3 commented Oct 4, 2023

The reachable_set analysis currently doesn't take the export-executable-symbols flag into account from what I can tell causing it to forget to include some #[no_mangle] functions in symbols.o.

@GoldsteinE
Copy link
Contributor

What’s stopping this from moving forward? Can I do something to help?

@Enselic Enselic added the F-export_executable_symbols `#![feature(export_executable_symbols)]` label Jul 13, 2024
@Enselic
Copy link
Member

Enselic commented Jul 13, 2024

Triage: Incidentally I just created a new label for this feature before I saw your comment on this issue.

A good first step would be to go through the issues in this query and triage them appropriately: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+Zexport-executable-symbols

Maybe #34131 can be closed as "covered by the tracking issue", for example.

@GoldsteinE
Copy link
Contributor

Thanks! I think I’ll look into #101610 first, because it affects the promised semantics of the flag.

@g-mero
Copy link

g-mero commented Sep 5, 2024

What's the current progress on this feature? It's been 3 years.

@bjorn3
Copy link
Member

bjorn3 commented Sep 5, 2024

It's still buggy afaik and I don't think anyone has been working to work on fixing the bugs it has.

@GoldsteinE
Copy link
Contributor

@g-mero It’s somewhere on my backlog, but I can’t promise getting to it soon. I think the problem in #101610 is either with version script or with linker arguments, so if you’d like to help, you can try to check whether symbols get to the version script. If they do, I think we should either use --dynamic-list or just --export-dynamic. Debugging this requires spending more time reading ld manuals than I currently have bandwidth for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC F-export_executable_symbols `#![feature(export_executable_symbols)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants