[Debug Info] Generate typedef nodes for ptr/ref types (and msvc arrays) #144394
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -117,7 +117,7 @@ fn build_fixed_size_array_di_node<'ll, 'tcx>( | |
| let subrange = unsafe { llvm::LLVMDIBuilderGetOrCreateSubrange(DIB(cx), 0, upper_bound) }; | ||
| let subscripts = &[subrange]; | ||
|
|
||
| let mut di_node = unsafe { | ||
| llvm::LLVMDIBuilderCreateArrayType( | ||
| DIB(cx), | ||
| size.bits(), | ||
|
|
@@ -128,6 +128,22 @@ fn build_fixed_size_array_di_node<'ll, 'tcx>( | |
| ) | ||
| }; | ||
|
|
||
| if cpp_like_debuginfo(cx.tcx) { | ||
| let array_type_name = compute_debuginfo_type_name(cx.tcx, array_type, false); | ||
| di_node = unsafe { | ||
| llvm::LLVMDIBuilderCreateTypedef( | ||
| DIB(cx), | ||
| di_node, | ||
| array_type_name.as_ptr(), | ||
| array_type_name.len(), | ||
| unknown_file_metadata(cx), | ||
| UNKNOWN_LINE_NUMBER, | ||
| None, | ||
| 0, | ||
| ) | ||
| }; | ||
| } | ||
|
|
||
| DINodeCreationResult::new(di_node, false) | ||
| } | ||
|
|
||
|
|
@@ -177,8 +193,20 @@ fn build_pointer_or_reference_di_node<'ll, 'tcx>( | |
| pointer_align.abi, | ||
| &ptr_type_debuginfo_name, | ||
| ); | ||
| let typedefed_ptr = unsafe { | ||
|
Member
There was a problem hiding this comment. As I've dug deeper, I've discovered that this program: fn foo(f: &usize) {
println!("Value: {}", f);
}
fn main() {
let x = 5;
foo(&x);
}with plain $ rustc -g /home/martin/src/main.rs && gdb -ex "b main::foo" -ex "run" -ex "ptype f" --args main
Breakpoint 1, main::foo (f=0x7fffffffe2b0) at /home/martin/src/main.rs:2
2 println!("Value: {}", f);
type = *mut usizeI've debugged gdb with gdb, and the reason is that gdb doesn't think the type have a name in this part of gdb code: case TYPE_CODE_PTR:
{
if (type->name () != nullptr)
gdb_puts (type->name (), stream);
else
{
/* We currently can't distinguish between pointers and
references. */
gdb_puts ("*mut ", stream);
type_print (type->target_type (), "", stream, 0);
}
}(For reference, here is the top of the gdb stacktrace to reach that code)But with So it looks like gdb wants to work well with Rust without any Python scripts. To me, it seems better to focus on getting the basics right, than to stack workarounds on top of each other. So, before we go ahead with something like this, I'd like to understand why gdb is not already working well for this case. Maybe it makes more sense to fix gdb. Disclaimer: There might very well be decisions or context I am missing. But this is where I stand right now.
Contributor
Author
There was a problem hiding this comment.
I'm not 100% clear on the implications of the wording, but
As I understand it, at the time GDB's rust support was written, the debug info output by rustc did not differentiate between the 5 types of indirection ( The major beneficiaries of this change are LLDB and microsoft's debugger(s). There are literally no alternatives on the PDB side of things because pointer nodes cannot store names at all, and because C/C++ reference and const semantics disagree with rust's (and we piggyback on C/C++ handling). For DWARF debug info with LLDB, the issue is LLDB uses the clang compiler's structs for type information. I'm not sure if clang's pointer struct even has a
Contributor
There was a problem hiding this comment.
Yes, that's correct, at least for compiler-generated entities. gdb tries not to know about library-defined types.
gdb started as a C debugger and sometimes there are still holes. In particular the DWARF reader seems to ignore a
Member
There was a problem hiding this comment.
Ok, then I would like to ask you to demonstrate that with diffs in I would like to again recommend to split this PR up into two. This is a quite complicated PR (in terms of impact), and anything we can do to minimize scope of discussion and impact of change is worthwhile, IMHO. Also, if you need to add new tests to demonstrate how the change affects the debugging experience, please add the test in a separate commit (maybe even separate PR), so that the diff of the impact of the change can easily be seen in a separate commit. Thanks! |
||
| llvm::LLVMDIBuilderCreateTypedef( | ||
| DIB(cx), | ||
| di_node, | ||
| ptr_type_debuginfo_name.as_ptr(), | ||
| ptr_type_debuginfo_name.len(), | ||
| unknown_file_metadata(cx), | ||
| UNKNOWN_LINE_NUMBER, | ||
| None, | ||
| 0, | ||
| ) | ||
| }; | ||
|
|
||
| DINodeCreationResult { di_node: typedefed_ptr, already_stored_in_typemap: false } | ||
| } | ||
| Some(wide_pointer_kind) => { | ||
| type_map::build_type_with_children( | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My apologies, but I still don't understand why we need to change both
fn build_pointer_or_reference_di_node()andfn build_fixed_size_array_di_node()in the same PR. They seem completely orthogonal to me. So far I've only looked at the change in the former.View changes since the review
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean i guess it could be. It's all sortof under the umbrella of "we try to give this information to the debugger, the debugger doesn't care, so we need a typedef to make it care". The context and reasoning are all the same and the implementations are almost identical.