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

Package debug libstd with binaries #20630

Open
brson opened this issue Jan 6, 2015 · 7 comments
Open

Package debug libstd with binaries #20630

brson opened this issue Jan 6, 2015 · 7 comments
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-feature-request Category: A feature request, i.e: not implemented / a PR. P-low Low priority T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.

Comments

@brson
Copy link
Contributor

brson commented Jan 6, 2015

For debugging it's useful to have a debug build of std. Figuring out how to make the debugger actually locate the source in all scenarios could be complicated.

@brson brson mentioned this issue Jan 6, 2015
65 tasks
@brson brson added the A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) label Jan 6, 2015
@brson
Copy link
Contributor Author

brson commented Jan 6, 2015

There are some options: we could just provide separate debuginfo for the optimized std, but we could also provide an unoptimized std with debuginfo.

@alexcrichton
Copy link
Member

I would personally be very worried about binary distribution size if we distribute yet another set of copies of the standard library, but the idea here sounds great!

@brson
Copy link
Contributor Author

brson commented Oct 18, 2015

Still something we want to do.

@retep998
Copy link
Member

I'd very much like an optional package that bundles .pdb debug info for the exe and dll binaries in the nightlies. Sometimes I want to debug what rustc is doing or profile it, and I can't really do it unless I build rustc from source.

@brson brson added the P-low Low priority label Aug 22, 2016
@Mark-Simulacrum Mark-Simulacrum added T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. and removed A-infrastructure labels Jun 25, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 22, 2017
@steveklabnik
Copy link
Member

Triage: no changes here. I wonder if we'll do this, or if we'll eventually get to "cargo aware std", where you can get your own debug build when building your project.

@jonas-schievink jonas-schievink added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) and removed A-build labels Apr 21, 2019
@pnkfelix
Copy link
Member

Visiting for wg-debugging triage

Some questions that we had while thinking about this:

  • What does a debuggable libstd mean? As brson wrote above: It could mean a libstd built in developer mode (which means debug_asserts enabled, and maybe also optimizations turned off). or it might just mean packaging the associated debuginfo for libstd.
  • In practice today, pnkfelix thinks the people who want to do this kind of deep dive into libstd itself are building their own Rust distribution. In theory, a -Zbuild-std option to cargo as alluded to by steveklabnik above would also provide that level of introspection into libstd (without requiring the same amount of effort as rebuilding the whole distribution).
    • So, the question: If we had working -Zbuild-std, are there people who would still want the project to distribute a debuggable libstd separately?
    • If so, is it solely because of the cost of doing the local build of libstd itself?

It seems like a very open question about whether we would do this at all at this point, and if we did, I suspect it would need to be driven by an RFC. Especially since, from our point of view, it is hard for the members of wg-debugging to understand the scenario where someone "wants to debug std but not as part of working on std"; we imagine that the best way to debug libstd is to make your own local build of rust. (If the real motivation here is "it is too costly to do a local build", then I can understand that. but I want to make sure that is indeed the key motivation.)

Anyway, as implied by the previous paragraph, I am currently thinking that we may want to close this issue, with the statement "If you want to propose this, please file an RFC." But I want to give other people the chance to weigh in, especially members of T-infra.

@jyn514
Copy link
Member

jyn514 commented Feb 3, 2023

Given the work on split-debuginfo, would it be possible to package the debuginfo in a separate file? That would avoid having to ship a second copy of the standard library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-feature-request Category: A feature request, i.e: not implemented / a PR. P-low Low priority T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

8 participants