How to step over multi-line statements e.g. struct literals

[DazWilkin]

VScode's support for Golang is mostly excellent.

One nit I have is when debugging|stepping through code, I'd prefer to not have to step through each line of multiline statements

e.g. struct literals:

d := &Dog{
	Name: "Freddie",
	Age:  2,
}
log.Printf("%+v", d)

Putting a breakpoint at &Dog takes 5 steps to jump over the initialization to the log line.

At first I suspected, it was deconstructing the literal into e.g. d.Name="Freddie" then d.Age=2 but the debugger does not show an incremental creation of the struct d and so I'm unclear of the benefit to this approach.

This behavior also occurs in other statements spread across multiple lines, e.g.:

log.Info("Log something",
  "Name", d.Name,
  "Age", d.Age,
)

I prefer this layout for readability but it's a pain when stepping through the code. Curiously, the log.Info statement is only 4 steps.

[hyangah]

That is related to how go is generating the debug info.

(dlv)  n
> main.main() ./main.go:13 (PC: 0x10cf721)
     8:         Name string
     9:         Age  int
    10: }
    11:
    12: func main() {
=>  13:         d := &Dog{
    14:                 Name: "Freddie",
    15:                 Age:  2,
    16:         }
    17:         log.Printf("%+v", d)
    18: }
(dlv) disassemble -l main.go:13
TEXT main.main(SB) /Users/hakim/projects/delve/main.go
        main.go:12      0x10cf700       65488b0c2530000000      mov rcx, qword ptr gs:[0x30]
        main.go:12      0x10cf709       483b6110                cmp rsp, qword ptr [rcx+0x10]
        main.go:12      0x10cf70d       0f86f8000000            jbe 0x10cf80b
        main.go:12      0x10cf713*      4883ec78                sub rsp, 0x78
        main.go:12      0x10cf717       48896c2470              mov qword ptr [rsp+0x70], rbp
        main.go:12      0x10cf71c       488d6c2470              lea rbp, ptr [rsp+0x70]
=>      main.go:13      0x10cf721       488d0518320100          lea rax, ptr [rip+0x13218]
        main.go:13      0x10cf728       48890424                mov qword ptr [rsp], rax
        main.go:13      0x10cf72c       e82fe6f3ff              call $runtime.newobject
        main.go:13      0x10cf731       488b7c2408              mov rdi, qword ptr [rsp+0x8]
        main.go:13      0x10cf736       48897c2438              mov qword ptr [rsp+0x38], rdi
        main.go:14      0x10cf73b       48c7470807000000        mov qword ptr [rdi+0x8], 0x7
        main.go:14      0x10cf743       833d067d0d0000          cmp dword ptr [runtime.writeBarrier], 0x0
        main.go:14      0x10cf74a       7405                    jz 0x10cf751
        main.go:14      0x10cf74c       e9a9000000              jmp 0x10cf7fa
        main.go:14      0x10cf751       488d0514560200          lea rax, ptr [rip+0x25614]
        main.go:14      0x10cf758       488907                  mov qword ptr [rdi], rax
        main.go:14      0x10cf75b       eb00                    jmp 0x10cf75d
        main.go:13      0x10cf75d       488b442438              mov rax, qword ptr [rsp+0x38]
        main.go:13      0x10cf762       8400                    test byte ptr [rax], al
        main.go:15      0x10cf764       48c7401002000000        mov qword ptr [rax+0x10], 0x2
        main.go:13      0x10cf76c       488b442438              mov rax, qword ptr [rsp+0x38]
        main.go:13      0x10cf771       4889442428              mov qword ptr [rsp+0x28], rax
        main.go:17      0x10cf776       4889442440              mov qword ptr [rsp+0x40], rax

When I want to skip many lines, I just place a new breakpoint up to the point that I want to skip and run continue.

The second example code is really a different code - e.g. no Dog object creation (runtime.newobject), no formatting, .. So, you are comparing apple and orange.

[DazWilkin]

Thanks for taking the time to reply!

Although I'm unfamiliar with the assembly, I'm aware that multiple statements underlie both statements.

My perspective is that this behavior is generally undesired and I'd prefer to be able to have the debugger treat multi-line statements as if there were one statement.

I wasn't comparing the assignment and the log statement; rather I was pointing out that the issue arises whenever I have multi-line statements like this.

[hyangah]

The debugger follows the mapping info to map a pc to a corresponding source line, and the mapping info is from the compilers. Debuggers often don't have direct access to the source code. Even when they do, they don't parse as the compilers would do. If you think compiler's debug info generation is incorrect and needs to be improved (often that's the case even though I am not sure about this specific example), file an issue in the Go issue tracker.