-
Notifications
You must be signed in to change notification settings - Fork 13.4k
libcompiler-builtins contains DWARF5 debuginfo in 1.62.0 #98746
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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: