-
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
debuginfo: by-value function parameters are not described correctly. #8512
Labels
A-debuginfo
Area: Debugging information in compiled programs (DWARF, PDB, etc.)
Comments
Update: After some research it seems that this is not fixable without LLVM modifications. That's the bad news. The good news is that clang has the same problem and there is some work under way to support this case in the The fix does not seem to be finished yet though. |
That llvm commit will probably get included in #8328 |
michaelwoerister
referenced
this issue
in michaelwoerister/rust
Aug 18, 2013
bors
added a commit
that referenced
this issue
Aug 31, 2013
This pull request includes * support for variables captured in closures*, * a fix for issue #8512: arguments of non-immediate type (structs, tuples, etc) passed by value can now be accessed correctly in GDB. (I managed to fix this by using `llvm::DIBuilder::createComplexVariable()`. However, I am not sure if this relies on unstable implementation details of LLVM's debug info handling. I'll try to clarify this on the LLVM mailing list). * simplification of the `debuginfo` module's public interface: the caller of functions like `create_local_var_metadata()` doesn't have to know and catch all cases when it mustn't call the function, * a cleanup refactoring with unified handling for locals, [self] arguments, captured variables, and match bindings, * and proper span information for self arguments. \* However, see comment at https://github.com/michaelwoerister/rust/blob/1d916ace136a27e354d73d65f488603c65f65bd2/src/test/debug-info/var-captured-in-nested-closure.rs#L62 . This is the same problem as with the fix for issue #8512 above: We are probably using `llvm.dbg.declare` in an unsupported way that works today but might not work after the next LLVM update. Cheers, Michael Fixes #8512 Fixes #1341
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Nov 21, 2022
Track `clippy.toml` and `Cargo.toml` in `file_depinfo` Causes cargo to re-run clippy when those paths are modified Also tracks the path to `clippy-driver` in debug mode to remove the workarounds in `cargo dev lint` and `lintcheck` (cc `@matthiaskrgr)` changelog: Automatically re-run Clippy if `Cargo.toml` or `clippy.toml` are modified Fixes rust-lang#2130 Fixes rust-lang#8512 r? `@flip1995`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, debug info for the following code will not be correct:
When breaking in
struct_fun()
GDB will report that there is no variable with nameby_val
. The reason is thatby_val
, having a non-immediate type, is really passed by reference as far as LLVM is concerned (seetrans::base::copy_args_to_allocas()
). Thety::t
associated with the value, however, is still the non-pointer type. LLVM does not seem to like this during codegen and silently omits the debug info entry for the parameter (seeCompileUnit::constructVariableDIE()
inllvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
). Consequently, GDB won't find anything for the nameby_val
.A fix will probably involve
DIBuilder::createComplexVariable()
.The text was updated successfully, but these errors were encountered: