-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
libcompiler-builtins contains DWARF5 debuginfo in 1.62.0 #98746
Comments
I am unfamiliar with Valgrind, but i updated a couple hours ago and i can't get LLDB to display local variables while debugging. Maybe related? It worked perfectly fine before the updated and i didn't change anything else. Tried common fixes, resetting, etc. |
This seems to have started somewhere between nightly-2022-04-28 and nightly-2022-04-29... and there's an LLVM update in the range. I'm going to bisect further with the bors builds. |
Yep, started on 1388b38. |
So... if I build 1388b38 locally, it doesn't reproduce... |
The CI change in 278fdf6 had the unintended side effect of shipping libcompiler-builtins with DWARF5 debuginfo, which is not well supported. |
For the record, libprofiler_builtins, and librustc-stable_rt.*san.a also have DWARF5 debuginfo. |
For the record (bis), my local builds of 1.62 were unaffected despite being compiled with clang 14 because they don't contain debuginfo in those libs at all. |
Rustc defaults to DWARF-2 on some targets, and DWARF-4 on others. However using -g with the C compiler yields whatever default version the C compiler prefers. One side effect is that the DWARF debug info shipped in some libraries with rustc itself (e.g. libcompiler_builtins and others) have recently switched to DWARF-5 have a side effect of upgrading the clang version used on rustc CI. (rust-lang/rust#98746) Ideally, the prefered DWARF version would be given by the rust compiler and/or cargo, but that's not the case at the moment, so the next best thing is something that aligns with the current defaults, although work in under way to add a rustc flag that would allow to pick the prefered DWARF version (rust-lang/rust#98350)
Rustc defaults to DWARF-2 on some targets, and DWARF-4 on others. However using -g with the C compiler yields whatever default version the C compiler prefers. One side effect is that the DWARF debug info shipped in some libraries with rustc itself (e.g. libcompiler_builtins and others) have recently switched to DWARF-5 as a side effect of upgrading the clang version used on rustc CI. (rust-lang/rust#98746) Ideally, the preferred DWARF version would be given by the rust compiler and/or cargo, but that's not the case at the moment, so the next best thing is something that aligns with the current defaults, although work in under way to add a rustc flag that would allow to pick the preferred DWARF version (rust-lang/rust#98350)
Rustc defaults to DWARF-2 on some targets, and DWARF-4 on others. However using -g with the C compiler yields whatever default version the C compiler prefers. One side effect is that the DWARF debug info shipped in some libraries with rustc itself (e.g. libcompiler_builtins and others) have recently switched to DWARF-5 as a side effect of upgrading the clang version used on rustc CI. (rust-lang/rust#98746) Ideally, the preferred DWARF version would be given by the rust compiler and/or cargo, but that's not the case at the moment, so the next best thing is something that aligns with the current defaults, although work in under way to add a rustc flag that would allow to pick the preferred DWARF version (rust-lang/rust#98350)
Rustc defaults to DWARF-2 on some targets, and DWARF-4 on others. However using -g with the C compiler yields whatever default version the C compiler prefers. One side effect is that the DWARF debug info shipped in some libraries with rustc itself (e.g. libcompiler_builtins and others) have recently switched to DWARF-5 as a side effect of upgrading the clang version used on rustc CI. (rust-lang/rust#98746) Ideally, the preferred DWARF version would be given by the rust compiler and/or cargo, but that's not the case at the moment, so the next best thing is something that aligns with the current defaults, although work in under way to add a rustc flag that would allow to pick the preferred DWARF version (rust-lang/rust#98350)
Although this probably isn't the right issue for that, this affects various rustup shims as well ( |
This also seems to prevent me from debugging binaries with rust code in gdb. For example with a C project that statically links a rust library on Ubuntu 20.04 with rustc/cargo 1.62.0 or 1.63.0:
Then gdb isn't able to show debugging symbols for most of the code. An llvm thread says this is a bug with DWARF 5 and gdb: https://discourse.llvm.org/t/gdb-10-1-cant-read-clangs-dwarf-v5/6035 It's only a single part of the binary that has DWARF version 5:
If I build my project with rustc/cargo 1.61.0, then I'm able to debug it in gdb and the above gdb error goes away. This underlying issue seems to be a bug with gdb < 10.1 (such as version 9.2 on ubuntu 20.04), but just wanted to mention a workflow that using DWARF 5 in compiler_builtins seems to break. |
FWIW, the next release of Valgrind (3.20) will have better support for DWARF 5 and should be out in the next week or two. |
@rustbot label: I-compiler-nominated nominating for discussion at T-compiler meeting.
|
Valgrind 3.20 has been released. |
Note that valgrind is not the only tool that has problems with DWARF 5. |
Also note there's been a PR on cc-rs for this for a while. |
@glandium I think you're referring to this one PR on cc-rs: rust-lang/cc-rs#694 (linking it here for reference) |
Assigning priority as suggestd in T-compiler meeting (Zulip discussion). @rustbot label -I-prioritize +P-high -I-compiler-nominated |
Rustc defaults to DWARF-2 on some targets, and DWARF-4 on others. However using -g with the C compiler yields whatever default version the C compiler prefers. One side effect is that the DWARF debug info shipped in some libraries with rustc itself (e.g. libcompiler_builtins and others) have recently switched to DWARF-5 as a side effect of upgrading the clang version used on rustc CI. (rust-lang/rust#98746) Ideally, the preferred DWARF version would be given by the rust compiler and/or cargo, but that's not the case at the moment, so the next best thing is something that aligns with the current defaults, although work in under way to add a rustc flag that would allow to pick the preferred DWARF version (rust-lang/rust#98350)
Rustc defaults to DWARF-2 on some targets, and DWARF-4 on others. However using -g with the C compiler yields whatever default version the C compiler prefers. One side effect is that the DWARF debug info shipped in some libraries with rustc itself (e.g. libcompiler_builtins and others) have recently switched to DWARF-5 as a side effect of upgrading the clang version used on rustc CI. (rust-lang/rust#98746) Ideally, the preferred DWARF version would be given by the rust compiler and/or cargo, but that's not the case at the moment, so the next best thing is something that aligns with the current defaults, although work in under way to add a rustc flag that would allow to pick the preferred DWARF version (rust-lang/rust#98350)
Fixes (without a test) rust-lang#98746.
Update cc to 1.0.77 Fixes (without a test) rust-lang#98746.
Update cc to 1.0.77 Fixes (without a test) rust-lang#98746.
Sadly Debian still doesn't have Valgrind 3.20, even in 'unstable', so this issue makes it quite hard to e.g. profile rustc performance issues on Debian. |
This should actually be fixed as of 5645d10 |
I'm still seeing these valgrind errors on current rustc (as in, when I am trying to profile rustc itself).
|
Oh indeed, while libcompiler_builtins is DWARF4, the rustc binary itself is DWARF5... |
... which is weird because the rust compiler itself defaults to emitting DWARF 4 at most. |
Building Firefox with rustc 1.62.0 on Linux and running it under valgrind makes valgrind emit the following error:
As of filing, I don't have more information to share yet, but I thought I'd already file it before starting to investigate it next week.
The text was updated successfully, but these errors were encountered: