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 defaulting to DWARF 5 format #75890

Closed
LifeIsStrange opened this issue Aug 24, 2020 · 6 comments
Closed

Tracking Issue for defaulting to DWARF 5 format #75890

LifeIsStrange opened this issue Aug 24, 2020 · 6 comments
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC

Comments

@LifeIsStrange
Copy link

LifeIsStrange commented Aug 24, 2020

https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-DWARF-5-Possible-Default
GCC 11 will enable DWARF 5 by default.
LLVM supports should be good as many backends already enable DWARF 5 by default, such as amdgpu or fuschia.

What are the blockers if any?
I don't think there is a flag to even enable it in an opt-in manner currently?

I think this could be a great improvement to rust as it could affect debug binaries performance, size and even correctness/allow things that weren't possible before, thus enabling future lldb/Gdb features.

@jonas-schievink
Copy link
Contributor

What new features would Rust benefit from with this?

@ehuss
Copy link
Contributor

ehuss commented Aug 24, 2020

I think one improvement would be split dwarf (#34651). I believe this would help reduce the size of executables when using the pre-compiled standard library (or at least not require stripping), and may have a performance improvement. Unfortunately it looks like there is still a long road to support that. It would be interesting to see an overview of what modern tooling supports (gcc, clang, gnu ld, lldb, gdb, etc.), since it seems like support has been spotty at best.

@camelid camelid added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC labels Oct 20, 2020
@LifeIsStrange
Copy link
Author

LifeIsStrange commented Jan 26, 2022

Update: LLVM Clang has switched to DWARFv5 by default.
@davidtwco friendly ping

@pnkfelix
Copy link
Member

pnkfelix commented Oct 14, 2022

see #98350; you can now (unstably, i.e. on nightly) opt-into DWARF5 on Linux

@pnkfelix
Copy link
Member

pnkfelix commented Oct 14, 2022

discussed at T-compiler steering meeting

we are not currently in a position to change all targets to DWARF5; it seems clear from issues like #98746 that support for DWARF 5 is inconsistent at best.

there is on-going work to allow one to opt-into using DWARF5, e.g. in already mentioned #98350. We should open a different tracking issue regarding offering stable support for that opt-in.

but defaulting to DWARF5 seems premature.

thus, closing this tracking issue.

@pnkfelix
Copy link
Member

Filed #103057 for the desire for a stable way to opt into DWARF5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC
Projects
None yet
Development

No branches or pull requests

5 participants