[Debug Info] Generate typedef nodes for ptr/ref types (and msvc arrays) #144394
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| 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. Disclaimer: There might very well be decisions or context I am missing. But this is where I stand right now. |
||
| 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( | ||
|
|
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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