Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.#128627
Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.#128627bors merged 5 commits intorust-lang:masterfrom
Conversation
…forms.
Line 0 has a special meaning in DWARF. From the version 5 spec:
The compiler may emit the value 0 in cases
where an instruction cannot be attributed to any
source line.
DUMMY_SP spans cannot be attributed to any line. However, because rustc
internally stores line numbers starting at zero, lookup_debug_loc() adjusts
every line number by one. Special casing DUMMY_SP to actually emit line 0
ensures rustc communicates to the debugger that there's no meaningful source
code for this instruction, rather than telling the debugger to jump to line 1
randomly.
|
r? @nnethercote rustbot has assigned @nnethercote. Use |
After deduplication the block conceptually belongs to multiple locations in the source. Although these blocks are unreachable, in rust-lang#123341 we did come across a real side effect, an unreachable block that survives into the compiled code can cause a debugger to set a breakpoint on the wrong instruction. Erasing the source information ensures that a debugger will never be misled into thinking that the unreachable block is worth setting a breakpoint on, especially after rust-lang#128627. Technically we don't need to erase the source information if all the deduplicated blocks have identical source information, but tracking that seems like more effort than it's worth.
jieyouxu
left a comment
There was a problem hiding this comment.
Is it possible to add a test for this?
|
And this probably need comment in code too? |
This comment has been minimized.
This comment has been minimized.
|
I agree a comment would be useful, particularly for explaining how/why MSVC is treated differently. |
…, r=nnethercote When deduplicating unreachable blocks, erase the source information. After deduplication the block conceptually belongs to multiple locations in the source. Although these blocks are unreachable, in rust-lang#123341 we did come across a real side effect, an unreachable block that survives into the compiled code can cause a debugger to set a breakpoint on the wrong instruction. Erasing the source information ensures that a debugger will never be misled into thinking that the unreachable block is worth setting a breakpoint on, especially after rust-lang#128627. Technically we don't need to erase the source information if all the deduplicated blocks have identical source information, but tracking that seems like more effort than it's worth. I'll let njn redirect this one too. r? `@nnethercote`
Rollup merge of rust-lang#128628 - khuey:simply-cfg-erase-source-info, r=nnethercote When deduplicating unreachable blocks, erase the source information. After deduplication the block conceptually belongs to multiple locations in the source. Although these blocks are unreachable, in rust-lang#123341 we did come across a real side effect, an unreachable block that survives into the compiled code can cause a debugger to set a breakpoint on the wrong instruction. Erasing the source information ensures that a debugger will never be misled into thinking that the unreachable block is worth setting a breakpoint on, especially after rust-lang#128627. Technically we don't need to erase the source information if all the deduplicated blocks have identical source information, but tracking that seems like more effort than it's worth. I'll let njn redirect this one too. r? `@nnethercote`
|
I added a comment and a test. The test is potentially fragile, if the code sample I used to emit a dummy span ever stops getting dummy spans the test will no longer test anything meaningful. But here's an example of the debug experience. Before: Breakpoint 1, tmp::main () at src/main.rs:5
5 let args = env::args();
(gdb) n
6 let number_str = args.skip(1).next().unwrap();
(gdb)
6 let number_str = args.skip(1).next().unwrap();
(gdb)
7 let number = number_str.parse::<i32>()?;
(gdb)
8 if number % 7 == 0 {
(gdb)
9 return Ok(());
(gdb)
1 use std::env;
(gdb)
13 }
(gdb)After Breakpoint 1, tmp::main () at src/main.rs:5
5 let args = env::args();
(gdb) n
6 let number_str = args.skip(1).next().unwrap();
(gdb)
6 let number_str = args.skip(1).next().unwrap();
(gdb)
7 let number = number_str.parse::<i32>()?;
(gdb)
8 if number % 7 == 0 {
(gdb)
9 return Ok(());
(gdb)
13 }
(gdb) The inexplicable (to the debugger user) jump to line 1 goes away. |
| // attributed to any line in the source. That's also exactly what dummy | ||
| // spans are. Make that equivalence here, rather than passing dummy spans | ||
| // to lookup_debug_loc, which will return line 1 for them. | ||
| let (line, col) = if span.is_dummy() && !self.sess().target.is_like_msvc { |
There was a problem hiding this comment.
It would be nice to have an is_dwarf() method rather than relying on the current-but-not-guaranteed-to-forever-be-true equivalence with is_like_msvc. But that's beyond the scope of this PR.
|
@bors r+ rollup |
Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.
Line 0 has a special meaning in DWARF. From the version 5 spec:
The compiler may emit the value 0 in cases
where an instruction cannot be attributed to any
source line.
DUMMY_SP spans cannot be attributed to any line. However, because rustc internally stores line numbers starting at zero, lookup_debug_loc() adjusts every line number by one. Special casing DUMMY_SP to actually emit line 0 ensures rustc communicates to the debugger that there's no meaningful source code for this instruction, rather than telling the debugger to jump to line 1 randomly.
Rollup of 6 pull requests Successful merges: - rust-lang#127623 (fix: fs::remove_dir_all: treat internal ENOENT as success) - rust-lang#128627 (Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.) - rust-lang#129187 (bootstrap: fix clean's remove_dir_all implementation) - rust-lang#129190 (Added f16 and f128 to tests/ui/consts/const-float-bits-conv.rs) - rust-lang#129231 (improve submodule updates) - rust-lang#129257 (Allow rust staticlib to work with MSVC's /WHOLEARCHIVE) r? `@ghost` `@rustbot` modify labels: rollup
Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.
Line 0 has a special meaning in DWARF. From the version 5 spec:
The compiler may emit the value 0 in cases
where an instruction cannot be attributed to any
source line.
DUMMY_SP spans cannot be attributed to any line. However, because rustc internally stores line numbers starting at zero, lookup_debug_loc() adjusts every line number by one. Special casing DUMMY_SP to actually emit line 0 ensures rustc communicates to the debugger that there's no meaningful source code for this instruction, rather than telling the debugger to jump to line 1 randomly.
Rollup of 6 pull requests Successful merges: - rust-lang#127623 (fix: fs::remove_dir_all: treat internal ENOENT as success) - rust-lang#128627 (Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.) - rust-lang#129187 (bootstrap: fix clean's remove_dir_all implementation) - rust-lang#129190 (Added f16 and f128 to tests/ui/consts/const-float-bits-conv.rs) - rust-lang#129231 (improve submodule updates) - rust-lang#129284 (rustdoc: animate the `:target` highlight) r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 6 pull requests Successful merges: - rust-lang#127623 (fix: fs::remove_dir_all: treat internal ENOENT as success) - rust-lang#128627 (Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.) - rust-lang#129187 (bootstrap: fix clean's remove_dir_all implementation) - rust-lang#129190 (Added f16 and f128 to tests/ui/consts/const-float-bits-conv.rs) - rust-lang#129231 (improve submodule updates) - rust-lang#129284 (rustdoc: animate the `:target` highlight) r? `@ghost` `@rustbot` modify labels: rollup
Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.
Line 0 has a special meaning in DWARF. From the version 5 spec:
The compiler may emit the value 0 in cases
where an instruction cannot be attributed to any
source line.
DUMMY_SP spans cannot be attributed to any line. However, because rustc internally stores line numbers starting at zero, lookup_debug_loc() adjusts every line number by one. Special casing DUMMY_SP to actually emit line 0 ensures rustc communicates to the debugger that there's no meaningful source code for this instruction, rather than telling the debugger to jump to line 1 randomly.
Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.
Line 0 has a special meaning in DWARF. From the version 5 spec:
The compiler may emit the value 0 in cases
where an instruction cannot be attributed to any
source line.
DUMMY_SP spans cannot be attributed to any line. However, because rustc internally stores line numbers starting at zero, lookup_debug_loc() adjusts every line number by one. Special casing DUMMY_SP to actually emit line 0 ensures rustc communicates to the debugger that there's no meaningful source code for this instruction, rather than telling the debugger to jump to line 1 randomly.
Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.
Line 0 has a special meaning in DWARF. From the version 5 spec:
The compiler may emit the value 0 in cases
where an instruction cannot be attributed to any
source line.
DUMMY_SP spans cannot be attributed to any line. However, because rustc internally stores line numbers starting at zero, lookup_debug_loc() adjusts every line number by one. Special casing DUMMY_SP to actually emit line 0 ensures rustc communicates to the debugger that there's no meaningful source code for this instruction, rather than telling the debugger to jump to line 1 randomly.
Rollup of 7 pull requests Successful merges: - rust-lang#128432 (WASI: forbid `unsafe_op_in_unsafe_fn` for `std::{os, sys}`) - rust-lang#128627 (Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.) - rust-lang#129187 (bootstrap: fix clean's remove_dir_all implementation) - rust-lang#129257 (Allow rust staticlib to work with MSVC's /WHOLEARCHIVE) - rust-lang#129264 (Update `library/Cargo.toml` in weekly job) - rust-lang#129284 (rustdoc: animate the `:target` highlight) - rust-lang#129332 (Avoid extra `cast()`s after `CStr::as_ptr()`) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#128627 (Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.) - rust-lang#128843 (Minor Refactor: Remove a Redundant Conditional Check) - rust-lang#129179 (CFI: Erase regions when projecting ADT to its transparent non-1zst field) - rust-lang#129281 (Tweak unreachable lint wording) - rust-lang#129312 (Fix stability attribute of `impl !Error for &str`) - rust-lang#129332 (Avoid extra `cast()`s after `CStr::as_ptr()`) - rust-lang#129339 (Make `ArgAbi::make_indirect_force` more specific) - rust-lang#129344 (Use `bool` in favor of `Option<()>` for diagnostics) - rust-lang#129345 (Use shorthand field initialization syntax more aggressively in the compiler) - rust-lang#129355 (fix comment on PlaceMention semantics) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#128627 - khuey:DUMMY_SP-line-no, r=nnethercote Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms. Line 0 has a special meaning in DWARF. From the version 5 spec: The compiler may emit the value 0 in cases where an instruction cannot be attributed to any source line. DUMMY_SP spans cannot be attributed to any line. However, because rustc internally stores line numbers starting at zero, lookup_debug_loc() adjusts every line number by one. Special casing DUMMY_SP to actually emit line 0 ensures rustc communicates to the debugger that there's no meaningful source code for this instruction, rather than telling the debugger to jump to line 1 randomly.
…ulacrum Refine dummy_span.rs test The test that is introduced in rust-lang#128627 is a BBs order problem in LLVM. I'm not 100% confident in the following investigation, but I think this is presumably the result. Per the following content that is mentioned at https://llvm.org/docs/KeyInstructionsDebugInfo.html: > DWARF provides a helpful tool the compiler can employ to mitigate this jumpiness, the `is_stmt` flag, which indicates that an instruction is a recommended breakpoint location. However, LLVM’s current approach to deciding `is_stmt` placement essentially reduces down to “is the associated line number different to the previous instruction’s?”. Taking the example from https://rust.godbolt.org/z/GvToxj6vh. The partial assembly code with `SimplifyComparisonIntegral` is: ```asm .LBB40_21: .loc 6 14 16 is_stmt 1 ; RET = Ok(()) mov byte ptr [rsp + 79], 5 .loc 6 0 0 is_stmt 0 jmp .LBB40_23 ... .LBB40_23: .loc 6 18 1 is_stmt 1 lea rdi, [rsp + 112] ; drop(number_str) call qword ptr [rip + core[270d1373c8f6a07d]::ptr::drop_in_place::<alloc[206d51544a00c3e8]::string::String>@GOTPCREL] jmp .LBB40_27 ``` without `SimplifyComparisonIntegral`: ```asm .LBB40_22: .loc 6 14 16 is_stmt 1 ; RET = Ok(()) mov byte ptr [rsp + 79], 5 .loc 6 0 0 is_stmt 0 jmp .LBB40_27 ... .LBB40_26: .loc 6 18 2 is_stmt 0 mov al, byte ptr [rsp + 79] .loc 6 18 2 epilogue_begin add rsp, 360 .cfi_def_cfa_offset 8 ret .LBB40_27: ; same line number to the previous instruction, so don't place `is_stmt` flag. ; this flag is `is_stmt 0` that will follow the flag of `.LBB40_26`. .loc 6 18 1 lea rdi, [rsp + 112] ; drop(number_str) call qword ptr [rip + core[270d1373c8f6a07d]::ptr::drop_in_place::<alloc[206d51544a00c3e8]::string::String>@GOTPCREL] jmp .LBB40_26 ``` GDB doesn't step to `LBB40_27` due to `is_stmt 0`, so the next step is `__rust_begin_short_backtrace`. I have verified the new test works well with or without ``SimplifyComparisonIntegral`.
…ulacrum Refine dummy_span.rs test The test that is introduced in rust-lang#128627 is a BBs order problem in LLVM. I'm not 100% confident in the following investigation, but I think this is presumably the result. Per the following content that is mentioned at https://llvm.org/docs/KeyInstructionsDebugInfo.html: > DWARF provides a helpful tool the compiler can employ to mitigate this jumpiness, the `is_stmt` flag, which indicates that an instruction is a recommended breakpoint location. However, LLVM’s current approach to deciding `is_stmt` placement essentially reduces down to “is the associated line number different to the previous instruction’s?”. Taking the example from https://rust.godbolt.org/z/GvToxj6vh. The partial assembly code with `SimplifyComparisonIntegral` is: ```asm .LBB40_21: .loc 6 14 16 is_stmt 1 ; RET = Ok(()) mov byte ptr [rsp + 79], 5 .loc 6 0 0 is_stmt 0 jmp .LBB40_23 ... .LBB40_23: .loc 6 18 1 is_stmt 1 lea rdi, [rsp + 112] ; drop(number_str) call qword ptr [rip + core[270d1373c8f6a07d]::ptr::drop_in_place::<alloc[206d51544a00c3e8]::string::String>@GOTPCREL] jmp .LBB40_27 ``` without `SimplifyComparisonIntegral`: ```asm .LBB40_22: .loc 6 14 16 is_stmt 1 ; RET = Ok(()) mov byte ptr [rsp + 79], 5 .loc 6 0 0 is_stmt 0 jmp .LBB40_27 ... .LBB40_26: .loc 6 18 2 is_stmt 0 mov al, byte ptr [rsp + 79] .loc 6 18 2 epilogue_begin add rsp, 360 .cfi_def_cfa_offset 8 ret .LBB40_27: ; same line number to the previous instruction, so don't place `is_stmt` flag. ; this flag is `is_stmt 0` that will follow the flag of `.LBB40_26`. .loc 6 18 1 lea rdi, [rsp + 112] ; drop(number_str) call qword ptr [rip + core[270d1373c8f6a07d]::ptr::drop_in_place::<alloc[206d51544a00c3e8]::string::String>@GOTPCREL] jmp .LBB40_26 ``` GDB doesn't step to `LBB40_27` due to `is_stmt 0`, so the next step is `__rust_begin_short_backtrace`. I have verified the new test works well with or without ``SimplifyComparisonIntegral`.
Line 0 has a special meaning in DWARF. From the version 5 spec:
DUMMY_SP spans cannot be attributed to any line. However, because rustc internally stores line numbers starting at zero, lookup_debug_loc() adjusts every line number by one. Special casing DUMMY_SP to actually emit line 0 ensures rustc communicates to the debugger that there's no meaningful source code for this instruction, rather than telling the debugger to jump to line 1 randomly.