Use the same DISubprogram for each instance of the same inlined function within a caller #114643

dpaoliello · 2023-08-09T00:13:41Z

Issue Details:

The call to panic within a function like Option::unwrap is translated to LLVM as a tail call (as it will never return), when multiple calls to the same function like this is inlined LLVM will notice the common tail call block (i.e., loading the same panic string + location info and then calling panic) and merge them together.

When merging these instructions together, LLVM will also attempt to merge the debug locations as well, but this fails (i.e., debug info is dropped) as Rust emits a new DISubprogram at each inline site thus LLVM doesn't recognize that these are actually the same function and so thinks that there isn't a common debug location.

As an example of this when building for x86_64 Windows (note the lack of .cv_loc before the call to panic, thus it will be attributed to the same line at the addq instruction):

	.cv_loc	0 1 23 0                        # src\lib.rs:23:0
	addq	$40, %rsp
	retq
	leaq	.Lalloc_f570dea0a53168780ce9a91e67646421(%rip), %rcx
	leaq	.Lalloc_629ace53b7e5b76aaa810d549cc84ea3(%rip), %r8
	movl	$43, %edx
	callq	_ZN4core9panicking5panic17h12e60b9063f6dee8E
	int3

Fix Details:

Cache the DISubprogram emitted for each inlined function instance within a caller so that this can be reused if that instance is encountered again, this also requires caching the DILexicalBlock and DIVariable objects to avoid creating duplicates.

After this change the above assembly now looks like:

	.cv_loc	0 1 23 0                        # src\lib.rs:23:0
	addq	$40, %rsp
	retq
	.cv_inline_site_id 5 within 0 inlined_at 1 0 0
	.cv_inline_site_id 6 within 5 inlined_at 1 12 0
	.cv_loc	6 2 935 0                       # library\core\src\option.rs:935:0
	leaq	.Lalloc_5f55955de67e57c79064b537689facea(%rip), %rcx
	leaq	.Lalloc_e741d4de8cb5801e1fd7a6c6795c1559(%rip), %r8
	movl	$43, %edx
	callq	_ZN4core9panicking5panic17hde1558f32d5b1c04E
	int3

rustbot · 2023-08-09T00:13:49Z

r? @fee1-dead

(rustbot has picked a reviewer for you, use r? to override)

rustbot · 2023-08-09T00:13:51Z

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo

fee1-dead · 2023-08-09T00:48:04Z

r? compiler

cjgillot · 2023-08-10T17:46:00Z

@bors try @rust-timer queue

bors · 2023-08-10T17:46:57Z

⌛ Trying commit 450caba2c72fb9909449b7fc2d09f1b47672244c with merge 4f0955dc1384542c3a8e0630c446c01ee2ccbd6c...

compiler/rustc_codegen_ssa/src/mir/debuginfo.rs

compiler/rustc_codegen_llvm/src/debuginfo/mod.rs

compiler/rustc_codegen_llvm/src/debuginfo/create_scope_map.rs

compiler/rustc_codegen_llvm/src/debuginfo/mod.rs

bors · 2023-08-10T20:11:49Z

💔 Test failed - checks-actions

compiler/rustc_codegen_llvm/src/debuginfo/create_scope_map.rs

bors · 2023-08-22T20:15:32Z

⌛ Testing commit 1097e09 with merge 154ae32...

bors · 2023-08-22T22:04:42Z

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing 154ae32 to master...

rust-timer · 2023-08-23T00:08:22Z

Finished benchmarking commit (154ae32): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.1%	[-1.1%, -1.1%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.4%	[-0.4%, -0.4%]	1
Improvements ✅ (secondary)	-3.7%	[-6.6%, -2.1%]	3
All ❌✅ (primary)	-0.4%	[-0.4%, -0.4%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.4%	[-0.8%, -0.0%]	62
Improvements ✅ (secondary)	-0.4%	[-1.6%, -0.0%]	18
All ❌✅ (primary)	-0.4%	[-0.8%, -0.0%]	62

Bootstrap: 635.929s -> 635.404s (-0.08%)
Artifact size: 347.06 MiB -> 347.06 MiB (-0.00%)

Use the same DISubprogram for each instance of the same inlined function within a caller # Issue Details: The call to `panic` within a function like `Option::unwrap` is translated to LLVM as a `tail call` (as it will never return), when multiple calls to the same function like this are inlined LLVM will notice the common `tail call` block (i.e., loading the same panic string + location info and then calling `panic`) and merge them together. When merging these instructions together, LLVM will also attempt to merge the debug locations as well, but this fails (i.e., debug info is dropped) as Rust emits a new `DISubprogram` at each inline site thus LLVM doesn't recognize that these are actually the same function and so thinks that there isn't a common debug location. As an example of this, consider the following program: ```rust #[no_mangle] fn add_numbers(x: &Option<i32>, y: &Option<i32>) -> i32 { let x1 = x.unwrap(); let y1 = y.unwrap(); x1 + y1 } ``` When building for x86_64 Windows using 1.72 it generates (note the lack of `.cv_loc` before the call to `panic`, thus it will be attributed to the same line at the `addq` instruction): ```llvm .cv_loc 0 1 3 0 # src\lib.rs:3:0 addq $40, %rsp retq leaq .Lalloc_f570dea0a53168780ce9a91e67646421(%rip), %rcx leaq .Lalloc_629ace53b7e5b76aaa810d549cc84ea3(%rip), %r8 movl $43, %edx callq _ZN4core9panicking5panic17h12e60b9063f6dee8E int3 ``` # Fix Details: Cache the `DISubprogram` emitted for each inlined function instance within a caller so that this can be reused if that instance is encountered again. Ideally, we would also deduplicate child scopes and variables, however my attempt to do that with rust-lang#114643 resulted in asserts when building for Linux (rust-lang#115156) which would require some deep changes to Rust to fix (rust-lang#115455). Instead, when using an inlined function as a debug scope, we will also create a new child scope such that subsequent child scopes and variables do not collide (from LLVM's perspective). After this change the above assembly now (with <https://reviews.llvm.org/D159226> as well) shows the `panic!` was inlined from `unwrap` in `option.rs` at line 935 into the current function in `lib.rs` at line 0 (line 0 is emitted since it is ambiguous which line to use as there were two inline sites that lead to this same code): ```llvm .cv_loc 0 1 3 0 # src\lib.rs:3:0 addq $40, %rsp retq .cv_inline_site_id 6 within 0 inlined_at 1 0 0 .cv_loc 6 2 935 0 # library\core\src\option.rs:935:0 leaq .Lalloc_5f55955de67e57c79064b537689facea(%rip), %rcx leaq .Lalloc_e741d4de8cb5801e1fd7a6c6795c1559(%rip), %r8 movl $43, %edx callq _ZN4core9panicking5panic17hde1558f32d5b1c04E int3 ```

…wiser Use the same DISubprogram for each instance of the same inlined function within a caller # Issue Details: The call to `panic` within a function like `Option::unwrap` is translated to LLVM as a `tail call` (as it will never return), when multiple calls to the same function like this is inlined LLVM will notice the common `tail call` block (i.e., loading the same panic string + location info and then calling `panic`) and merge them together. When merging these instructions together, LLVM will also attempt to merge the debug locations as well, but this fails (i.e., debug info is dropped) as Rust emits a new `DISubprogram` at each inline site thus LLVM doesn't recognize that these are actually the same function and so thinks that there isn't a common debug location. As an example of this when building for x86_64 Windows (note the lack of `.cv_loc` before the call to `panic`, thus it will be attributed to the same line at the `addq` instruction): ``` .cv_loc 0 1 23 0 # src\lib.rs:23:0 addq $40, %rsp retq leaq .Lalloc_f570dea0a53168780ce9a91e67646421(%rip), %rcx leaq .Lalloc_629ace53b7e5b76aaa810d549cc84ea3(%rip), %r8 movl $43, %edx callq _ZN4core9panicking5panic17h12e60b9063f6dee8E int3 ``` # Fix Details: Cache the `DISubprogram` emitted for each inlined function instance within a caller so that this can be reused if that instance is encountered again, this also requires caching the `DILexicalBlock` and `DIVariable` objects to avoid creating duplicates. After this change the above assembly now looks like: ``` .cv_loc 0 1 23 0 # src\lib.rs:23:0 addq $40, %rsp retq .cv_inline_site_id 5 within 0 inlined_at 1 0 0 .cv_inline_site_id 6 within 5 inlined_at 1 12 0 .cv_loc 6 2 935 0 # library\core\src\option.rs:935:0 leaq .Lalloc_5f55955de67e57c79064b537689facea(%rip), %rcx leaq .Lalloc_e741d4de8cb5801e1fd7a6c6795c1559(%rip), %r8 movl $43, %edx callq _ZN4core9panicking5panic17hde1558f32d5b1c04E int3 ```

…gers. Line numbers of multiply-inlined functions were fixed in rust-lang#114643 by using a DISubprogram. That, however, triggered assertions because parameters weren't deduplicated. The "solution" to that in rust-lang#115417 was to insert a DILexicalScope below the DISubprogram and parent all of the parameters to that scope. That fixed the assertion, but debuggers (including gdb and lldb) don't recognize variables that are not parented to the subprogram itself as parameters, even if they are emitted with DW_TAG_formal_parameter. Consider the program: use std::env; fn square(n: i32) -> i32 { n * n } fn square_no_inline(n: i32) -> i32 { n * n } fn main() { let x = square(env::vars().count() as i32); let y = square_no_inline(env::vars().count() as i32); println!("{x} == {y}"); } When making a release build with debug=2 and rustc 1.82.0-nightly (8b38707 2024-08-07) (gdb) r Starting program: /ephemeral/tmp/target/release/tmp [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, tmp::square () at src/main.rs:5 5 n * n (gdb) info args No arguments. (gdb) info locals n = 31 (gdb) c Continuing. Breakpoint 2, tmp::square_no_inline (n=31) at src/main.rs:10 10 n * n (gdb) info args n = 31 (gdb) info locals No locals. This issue is particularly annoying because it removes arguments from stack traces. The DWARF for the inlined function looks like this: < 2><0x00002132 GOFF=0x00002132> DW_TAG_subprogram DW_AT_linkage_name _ZN3tmp6square17hc507052ff3d2a488E DW_AT_name square DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> DW_AT_inline DW_INL_inlined < 3><0x00002142 GOFF=0x00002142> DW_TAG_lexical_block < 4><0x00002143 GOFF=0x00002143> DW_TAG_formal_parameter DW_AT_name n DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> < 4><0x0000214e GOFF=0x0000214e> DW_TAG_null < 3><0x0000214f GOFF=0x0000214f> DW_TAG_null That DW_TAG_lexical_block inhibits every debugger I've tested from recognizing 'n' as a parameter. This patch removes the additional lexical scope. Parameters can be easily deduplicated by a tuple of their scope and the argument index, at the trivial cost of taking a Hash + Eq bound on DIScope.

…gers. Line numbers of multiply-inlined functions were fixed in rust-lang#114643 by using a single DISubprogram. That, however, triggered assertions because parameters weren't deduplicated. The "solution" to that in rust-lang#115417 was to insert a DILexicalScope below the DISubprogram and parent all of the parameters to that scope. That fixed the assertion, but debuggers (including gdb and lldb) don't recognize variables that are not parented to the subprogram itself as parameters, even if they are emitted with DW_TAG_formal_parameter. Consider the program: use std::env; fn square(n: i32) -> i32 { n * n } fn square_no_inline(n: i32) -> i32 { n * n } fn main() { let x = square(env::vars().count() as i32); let y = square_no_inline(env::vars().count() as i32); println!("{x} == {y}"); } When making a release build with debug=2 and rustc 1.82.0-nightly (8b38707 2024-08-07) (gdb) r Starting program: /ephemeral/tmp/target/release/tmp [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, tmp::square () at src/main.rs:5 5 n * n (gdb) info args No arguments. (gdb) info locals n = 31 (gdb) c Continuing. Breakpoint 2, tmp::square_no_inline (n=31) at src/main.rs:10 10 n * n (gdb) info args n = 31 (gdb) info locals No locals. This issue is particularly annoying because it removes arguments from stack traces. The DWARF for the inlined function looks like this: < 2><0x00002132 GOFF=0x00002132> DW_TAG_subprogram DW_AT_linkage_name _ZN3tmp6square17hc507052ff3d2a488E DW_AT_name square DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> DW_AT_inline DW_INL_inlined < 3><0x00002142 GOFF=0x00002142> DW_TAG_lexical_block < 4><0x00002143 GOFF=0x00002143> DW_TAG_formal_parameter DW_AT_name n DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> < 4><0x0000214e GOFF=0x0000214e> DW_TAG_null < 3><0x0000214f GOFF=0x0000214f> DW_TAG_null That DW_TAG_lexical_block inhibits every debugger I've tested from recognizing 'n' as a parameter. This patch removes the additional lexical scope. Parameters can be easily deduplicated by a tuple of their scope and the argument index, at the trivial cost of taking a Hash + Eq bound on DIScope.

…ginfo, r=wesleywiser Rework MIR inlining debuginfo so function parameters show up in debuggers. Line numbers of multiply-inlined functions were fixed in rust-lang#114643 by using a single DISubprogram. That, however, triggered assertions because parameters weren't deduplicated. The "solution" to that in rust-lang#115417 was to insert a DILexicalScope below the DISubprogram and parent all of the parameters to that scope. That fixed the assertion, but debuggers (including gdb and lldb) don't recognize variables that are not parented to the subprogram itself as parameters, even if they are emitted with DW_TAG_formal_parameter. Consider the program: ```rust use std::env; #[inline(always)] fn square(n: i32) -> i32 { n * n } #[inline(never)] fn square_no_inline(n: i32) -> i32 { n * n } fn main() { let x = square(env::vars().count() as i32); let y = square_no_inline(env::vars().count() as i32); println!("{x} == {y}"); } ``` When making a release build with debug=2 and rustc 1.82.0-nightly (8b38707 2024-08-07) ``` (gdb) r Starting program: /ephemeral/tmp/target/release/tmp [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, tmp::square () at src/main.rs:5 5 n * n (gdb) info args No arguments. (gdb) info locals n = 31 (gdb) c Continuing. Breakpoint 2, tmp::square_no_inline (n=31) at src/main.rs:10 10 n * n (gdb) info args n = 31 (gdb) info locals No locals. ``` This issue is particularly annoying because it removes arguments from stack traces. The DWARF for the inlined function looks like this: ``` < 2><0x00002132 GOFF=0x00002132> DW_TAG_subprogram DW_AT_linkage_name _ZN3tmp6square17hc507052ff3d2a488E DW_AT_name square DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> DW_AT_inline DW_INL_inlined < 3><0x00002142 GOFF=0x00002142> DW_TAG_lexical_block < 4><0x00002143 GOFF=0x00002143> DW_TAG_formal_parameter DW_AT_name n DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> < 4><0x0000214e GOFF=0x0000214e> DW_TAG_null < 3><0x0000214f GOFF=0x0000214f> DW_TAG_null ``` That DW_TAG_lexical_block inhibits every debugger I've tested from recognizing 'n' as a parameter. This patch removes the additional lexical scope. Parameters can be easily deduplicated by a tuple of their scope and the argument index, at the trivial cost of taking a Hash + Eq bound on DIScope.

…gers. Line numbers of multiply-inlined functions were fixed in rust-lang#114643 by using a single DISubprogram. That, however, triggered assertions because parameters weren't deduplicated. The "solution" to that in rust-lang#115417 was to insert a DILexicalScope below the DISubprogram and parent all of the parameters to that scope. That fixed the assertion, but debuggers (including gdb and lldb) don't recognize variables that are not parented to the subprogram itself as parameters, even if they are emitted with DW_TAG_formal_parameter. Consider the program: use std::env; fn square(n: i32) -> i32 { n * n } fn square_no_inline(n: i32) -> i32 { n * n } fn main() { let x = square(env::vars().count() as i32); let y = square_no_inline(env::vars().count() as i32); println!("{x} == {y}"); } When making a release build with debug=2 and rustc 1.82.0-nightly (8b38707 2024-08-07) (gdb) r Starting program: /ephemeral/tmp/target/release/tmp [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, tmp::square () at src/main.rs:5 5 n * n (gdb) info args No arguments. (gdb) info locals n = 31 (gdb) c Continuing. Breakpoint 2, tmp::square_no_inline (n=31) at src/main.rs:10 10 n * n (gdb) info args n = 31 (gdb) info locals No locals. This issue is particularly annoying because it removes arguments from stack traces. The DWARF for the inlined function looks like this: < 2><0x00002132 GOFF=0x00002132> DW_TAG_subprogram DW_AT_linkage_name _ZN3tmp6square17hc507052ff3d2a488E DW_AT_name square DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> DW_AT_inline DW_INL_inlined < 3><0x00002142 GOFF=0x00002142> DW_TAG_lexical_block < 4><0x00002143 GOFF=0x00002143> DW_TAG_formal_parameter DW_AT_name n DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> < 4><0x0000214e GOFF=0x0000214e> DW_TAG_null < 3><0x0000214f GOFF=0x0000214f> DW_TAG_null That DW_TAG_lexical_block inhibits every debugger I've tested from recognizing 'n' as a parameter. This patch removes the additional lexical scope. Parameters can be easily deduplicated by a tuple of their scope and the argument index, at the trivial cost of taking a Hash + Eq bound on DIScope.

…nfo, r=<try> Rework MIR inlining debuginfo so function parameters show up in debuggers. Line numbers of multiply-inlined functions were fixed in rust-lang#114643 by using a single DISubprogram. That, however, triggered assertions because parameters weren't deduplicated. The "solution" to that in rust-lang#115417 was to insert a DILexicalScope below the DISubprogram and parent all of the parameters to that scope. That fixed the assertion, but debuggers (including gdb and lldb) don't recognize variables that are not parented to the subprogram itself as parameters, even if they are emitted with DW_TAG_formal_parameter. Consider the program: ```rust use std::env; #[inline(always)] fn square(n: i32) -> i32 { n * n } #[inline(never)] fn square_no_inline(n: i32) -> i32 { n * n } fn main() { let x = square(env::vars().count() as i32); let y = square_no_inline(env::vars().count() as i32); println!("{x} == {y}"); } ``` When making a release build with debug=2 and rustc 1.82.0-nightly (8b38707 2024-08-07) ``` (gdb) r Starting program: /ephemeral/tmp/target/release/tmp [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, tmp::square () at src/main.rs:5 5 n * n (gdb) info args No arguments. (gdb) info locals n = 31 (gdb) c Continuing. Breakpoint 2, tmp::square_no_inline (n=31) at src/main.rs:10 10 n * n (gdb) info args n = 31 (gdb) info locals No locals. ``` This issue is particularly annoying because it removes arguments from stack traces. The DWARF for the inlined function looks like this: ``` < 2><0x00002132 GOFF=0x00002132> DW_TAG_subprogram DW_AT_linkage_name _ZN3tmp6square17hc507052ff3d2a488E DW_AT_name square DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> DW_AT_inline DW_INL_inlined < 3><0x00002142 GOFF=0x00002142> DW_TAG_lexical_block < 4><0x00002143 GOFF=0x00002143> DW_TAG_formal_parameter DW_AT_name n DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> < 4><0x0000214e GOFF=0x0000214e> DW_TAG_null < 3><0x0000214f GOFF=0x0000214f> DW_TAG_null ``` That DW_TAG_lexical_block inhibits every debugger I've tested from recognizing 'n' as a parameter. This patch removes the additional lexical scope. Parameters can be easily deduplicated by a tuple of their scope and the argument index, at the trivial cost of taking a Hash + Eq bound on DIScope. try-job: x86_64-msvc try-job: i686-mingw

…gers. Line numbers of multiply-inlined functions were fixed in rust-lang#114643 by using a single DISubprogram. That, however, triggered assertions because parameters weren't deduplicated. The "solution" to that in rust-lang#115417 was to insert a DILexicalScope below the DISubprogram and parent all of the parameters to that scope. That fixed the assertion, but debuggers (including gdb and lldb) don't recognize variables that are not parented to the subprogram itself as parameters, even if they are emitted with DW_TAG_formal_parameter. Consider the program: use std::env; fn square(n: i32) -> i32 { n * n } fn square_no_inline(n: i32) -> i32 { n * n } fn main() { let x = square(env::vars().count() as i32); let y = square_no_inline(env::vars().count() as i32); println!("{x} == {y}"); } When making a release build with debug=2 and rustc 1.82.0-nightly (8b38707 2024-08-07) (gdb) r Starting program: /ephemeral/tmp/target/release/tmp [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, tmp::square () at src/main.rs:5 5 n * n (gdb) info args No arguments. (gdb) info locals n = 31 (gdb) c Continuing. Breakpoint 2, tmp::square_no_inline (n=31) at src/main.rs:10 10 n * n (gdb) info args n = 31 (gdb) info locals No locals. This issue is particularly annoying because it removes arguments from stack traces. The DWARF for the inlined function looks like this: < 2><0x00002132 GOFF=0x00002132> DW_TAG_subprogram DW_AT_linkage_name _ZN3tmp6square17hc507052ff3d2a488E DW_AT_name square DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> DW_AT_inline DW_INL_inlined < 3><0x00002142 GOFF=0x00002142> DW_TAG_lexical_block < 4><0x00002143 GOFF=0x00002143> DW_TAG_formal_parameter DW_AT_name n DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> < 4><0x0000214e GOFF=0x0000214e> DW_TAG_null < 3><0x0000214f GOFF=0x0000214f> DW_TAG_null That DW_TAG_lexical_block inhibits every debugger I've tested from recognizing 'n' as a parameter. This patch removes the additional lexical scope. Parameters can be easily deduplicated by a tuple of their scope and the argument index, at the trivial cost of taking a Hash + Eq bound on DIScope.

…nfo, r=<try> Rework MIR inlining debuginfo so function parameters show up in debuggers. Line numbers of multiply-inlined functions were fixed in rust-lang#114643 by using a single DISubprogram. That, however, triggered assertions because parameters weren't deduplicated. The "solution" to that in rust-lang#115417 was to insert a DILexicalScope below the DISubprogram and parent all of the parameters to that scope. That fixed the assertion, but debuggers (including gdb and lldb) don't recognize variables that are not parented to the subprogram itself as parameters, even if they are emitted with DW_TAG_formal_parameter. Consider the program: ```rust use std::env; #[inline(always)] fn square(n: i32) -> i32 { n * n } #[inline(never)] fn square_no_inline(n: i32) -> i32 { n * n } fn main() { let x = square(env::vars().count() as i32); let y = square_no_inline(env::vars().count() as i32); println!("{x} == {y}"); } ``` When making a release build with debug=2 and rustc 1.82.0-nightly (8b38707 2024-08-07) ``` (gdb) r Starting program: /ephemeral/tmp/target/release/tmp [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, tmp::square () at src/main.rs:5 5 n * n (gdb) info args No arguments. (gdb) info locals n = 31 (gdb) c Continuing. Breakpoint 2, tmp::square_no_inline (n=31) at src/main.rs:10 10 n * n (gdb) info args n = 31 (gdb) info locals No locals. ``` This issue is particularly annoying because it removes arguments from stack traces. The DWARF for the inlined function looks like this: ``` < 2><0x00002132 GOFF=0x00002132> DW_TAG_subprogram DW_AT_linkage_name _ZN3tmp6square17hc507052ff3d2a488E DW_AT_name square DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> DW_AT_inline DW_INL_inlined < 3><0x00002142 GOFF=0x00002142> DW_TAG_lexical_block < 4><0x00002143 GOFF=0x00002143> DW_TAG_formal_parameter DW_AT_name n DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> < 4><0x0000214e GOFF=0x0000214e> DW_TAG_null < 3><0x0000214f GOFF=0x0000214f> DW_TAG_null ``` That DW_TAG_lexical_block inhibits every debugger I've tested from recognizing 'n' as a parameter. This patch removes the additional lexical scope. Parameters can be easily deduplicated by a tuple of their scope and the argument index, at the trivial cost of taking a Hash + Eq bound on DIScope. try-job: x86_64-msvc try-job: i686-mingw

…nfo, r=wesleywiser Rework MIR inlining debuginfo so function parameters show up in debuggers. Line numbers of multiply-inlined functions were fixed in rust-lang#114643 by using a single DISubprogram. That, however, triggered assertions because parameters weren't deduplicated. The "solution" to that in rust-lang#115417 was to insert a DILexicalScope below the DISubprogram and parent all of the parameters to that scope. That fixed the assertion, but debuggers (including gdb and lldb) don't recognize variables that are not parented to the subprogram itself as parameters, even if they are emitted with DW_TAG_formal_parameter. Consider the program: ```rust use std::env; #[inline(always)] fn square(n: i32) -> i32 { n * n } #[inline(never)] fn square_no_inline(n: i32) -> i32 { n * n } fn main() { let x = square(env::vars().count() as i32); let y = square_no_inline(env::vars().count() as i32); println!("{x} == {y}"); } ``` When making a release build with debug=2 and rustc 1.82.0-nightly (8b38707 2024-08-07) ``` (gdb) r Starting program: /ephemeral/tmp/target/release/tmp [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, tmp::square () at src/main.rs:5 5 n * n (gdb) info args No arguments. (gdb) info locals n = 31 (gdb) c Continuing. Breakpoint 2, tmp::square_no_inline (n=31) at src/main.rs:10 10 n * n (gdb) info args n = 31 (gdb) info locals No locals. ``` This issue is particularly annoying because it removes arguments from stack traces. The DWARF for the inlined function looks like this: ``` < 2><0x00002132 GOFF=0x00002132> DW_TAG_subprogram DW_AT_linkage_name _ZN3tmp6square17hc507052ff3d2a488E DW_AT_name square DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> DW_AT_inline DW_INL_inlined < 3><0x00002142 GOFF=0x00002142> DW_TAG_lexical_block < 4><0x00002143 GOFF=0x00002143> DW_TAG_formal_parameter DW_AT_name n DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> < 4><0x0000214e GOFF=0x0000214e> DW_TAG_null < 3><0x0000214f GOFF=0x0000214f> DW_TAG_null ``` That DW_TAG_lexical_block inhibits every debugger I've tested from recognizing 'n' as a parameter. This patch removes the additional lexical scope. Parameters can be easily deduplicated by a tuple of their scope and the argument index, at the trivial cost of taking a Hash + Eq bound on DIScope.

…gers. Line numbers of multiply-inlined functions were fixed in rust-lang#114643 by using a single DISubprogram. That, however, triggered assertions because parameters weren't deduplicated. The "solution" to that in rust-lang#115417 was to insert a DILexicalScope below the DISubprogram and parent all of the parameters to that scope. That fixed the assertion, but debuggers (including gdb and lldb) don't recognize variables that are not parented to the subprogram itself as parameters, even if they are emitted with DW_TAG_formal_parameter. Consider the program: use std::env; fn square(n: i32) -> i32 { n * n } fn square_no_inline(n: i32) -> i32 { n * n } fn main() { let x = square(env::vars().count() as i32); let y = square_no_inline(env::vars().count() as i32); println!("{x} == {y}"); } When making a release build with debug=2 and rustc 1.82.0-nightly (8b38707 2024-08-07) (gdb) r Starting program: /ephemeral/tmp/target/release/tmp [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, tmp::square () at src/main.rs:5 5 n * n (gdb) info args No arguments. (gdb) info locals n = 31 (gdb) c Continuing. Breakpoint 2, tmp::square_no_inline (n=31) at src/main.rs:10 10 n * n (gdb) info args n = 31 (gdb) info locals No locals. This issue is particularly annoying because it removes arguments from stack traces. The DWARF for the inlined function looks like this: < 2><0x00002132 GOFF=0x00002132> DW_TAG_subprogram DW_AT_linkage_name _ZN3tmp6square17hc507052ff3d2a488E DW_AT_name square DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> DW_AT_inline DW_INL_inlined < 3><0x00002142 GOFF=0x00002142> DW_TAG_lexical_block < 4><0x00002143 GOFF=0x00002143> DW_TAG_formal_parameter DW_AT_name n DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> < 4><0x0000214e GOFF=0x0000214e> DW_TAG_null < 3><0x0000214f GOFF=0x0000214f> DW_TAG_null That DW_TAG_lexical_block inhibits every debugger I've tested from recognizing 'n' as a parameter. This patch removes the additional lexical scope. Parameters can be easily deduplicated by a tuple of their scope and the argument index, at the trivial cost of taking a Hash + Eq bound on DIScope.

rustbot assigned fee1-dead Aug 9, 2023

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 9, 2023