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

debuginfo: by-value function parameters are not described correctly. #8512

Closed
michaelwoerister opened this issue Aug 14, 2013 · 2 comments
Closed
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.)

Comments

@michaelwoerister
Copy link
Member

Currently, debug info for the following code will not be correct:

struct Struct {
    a: int,
    b: float
}

fn struct_fun(by_val: Struct) {
    {...}
}

When breaking in struct_fun() GDB will report that there is no variable with name by_val. The reason is that by_val, having a non-immediate type, is really passed by reference as far as LLVM is concerned (see trans::base::copy_args_to_allocas()). The ty::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 (see CompileUnit::constructVariableDIE() in llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp). Consequently, GDB won't find anything for the name by_val.

A fix will probably involve DIBuilder::createComplexVariable().

@michaelwoerister
Copy link
Member Author

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 DIBuilder: llvm-mirror/llvm@c971cb8

The fix does not seem to be finished yet though.

@alexcrichton
Copy link
Member

That llvm commit will probably get included in #8328

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
@bors bors closed this as completed in 45c3ca7 Sep 4, 2013
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
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants