click on line claims "never executed", but click on stdout jumps right to that line

[pnkfelix]

Go here

https://pernos.co/debug/KB5oDSG2Tb88ia9GtUV7HQ/index.html#f{m[Dks,G1U_,t[Aw,Iarw_,f{e[DkI,ASt4_,s{aViQTZaAA,b2g,uKt5U,oKxgl___/

i.e. main.rs:40

Try clicking on line 41.

For me, it says "main.rs:41 is never executed" in the "Executions of main.rs:41" window.

But then when I clck on line 4 of the stdout view (" - main @Span { id: 0, repr: "src/main.rs:25:1: 25:22" }") , it jumps right to main.rs:41

(Is this a bug in the dwarf output being generated by rustc, or a bug in the pernos.co UI?)

[khuey]

This is a Pernosco bug.

[khuey]

Arguably this is actually a compiler bug that gdb just copes with better than we do. Here's the line number program

...
0x00027d5a  [  41,35] NS
0x00027d64  [  44,20] NS
0x00027d79  [   0,20]
0x00027d93  [ 930, 9] NS uri: "/rustc/1684a753dbca5d23b2e03568e6fbbb48eb72d0e6/library/core/src/option.rs"
0x00027d9e  [ 932,21] NS
0x00027db2  [ 931,18] NS
0x00027dc7  [   0,18]
0x00027dcc  [  44,20] NS uri: "src/main.rs"
0x00027dd4  [  45,26] NS
0x00027de7  [1075, 9] NS uri: "/rustc/1684a753dbca5d23b2e03568e6fbbb48eb72d0e6/library/core/src/result.rs"
0x00027df6  [1077,17] NS
0x00027e16  [1077,23]
0x00027e43  [   0,23]
0x00027e5f  [1077,86]
0x00027e66  [   0,86]
0x00027e68  [1071, 5] NS
0x00027e8e  [1076,16] NS
0x00027ebe  [  46, 5] NS uri: "src/main.rs"
0x00027eed  [  47, 5] NS
0x00027ef5  [  48, 1] NS
0x00027f02  [  48, 2]
0x00027f0e  [  48, 2] EB
0x00027f16  [   0, 2]
0x00027f26  [  97,22] NS uri: "/rustc/1684a753dbca5d23b2e03568e6fbbb48eb72d0e6/library/core/src/fmt/rt.rs"
0x00027f35  [  92,18] NS
0x00027f45  [  98, 6] NS
0x00027f61  [   0, 6]
0x00027f69  [  41, 9] NS uri: "src/main.rs"
0x00027f73  [   0, 9]
0x00027f9d  [  41,48]
0x00027fb5  [   0,48]
0x00027fba  [  41,48]
0x00027fd2  [ 101,22] NS uri: "/rustc/1684a753dbca5d23b2e03568e6fbbb48eb72d0e6/library/core/src/fmt/rt.rs"
0x00027fe1  [  92,18] NS
0x00027ff1  [ 102, 6] NS
0x0002800b  [   0, 6]
0x0002801f  [  41, 9] NS uri: "src/main.rs"
0x0002807b  [   0, 9]
0x00028083  [  41, 9]
...

The first line that I've included, 0x00027d5a, is the first appearance of line 41 in the line number table and is where gdb chooses to set a breakpoint. Note that it has the "NS" marker, which corresponds to is_stmt=1 in the DWARF line number program. The DWARF spec states is_stmt is

A boolean indicating that the current instruction is a recommended breakpoint location. A recommended breakpoint location is intended to “represent” a line, a statement and/or a semantically distinct subpart of a statement.

At line 0x00027f0e you see the "EB" marker for "epilogue begin". Then there are two additional lines corresponding to line 41 (at 0x00027f69 and 0x0002801f) that also have the "NS" markers. These is definitely clean up code. Both 27f69 and 28083 are calls to _ZN4core3ptr42drop_in_place$LT$alloc..string..String$GT$17hfc1c5af03419ab89E, for example. These should probably not have the "NS" marker set.

The difference in behavior between gdb and Pernosco is because when multiple statements are present for the same line gdb chooses the first one in machine code order and Pernosco chooses the first one in source order. I checked in a patch to Pernosco that switches to machine code order so we'll cope with this sort of thing better.

[khuey]

Fix is deployed.