debugging: redirect flag not working with dlv-dap adapter

[hyangah]

--redirect or -r flag is ignored in dlv dap which is understandable because dlv dap won't know what it will do until the launch/attach request arrives. One option is to launch dlv debug --headless --listen=:12345 -r ... externally (define in tasks.json) and connect it as a preTask of a launch.json configuration). However, not very convenient.

Either

1. we make dlv dap supports stdin/stdout/stderr redirect from launch configuration, or
2. we make dlv dap accepts -r flags and use them for the future request. (drawback: the concept doesn't map cleanly imo), or
3. we implement from the thin adapter, (drawback: this is available only to vscode users, which isn't nice)

Discussed in https://github.com/golang/vscode-go/discussions/2136

^{Originally posted by mlizd March 24, 2022} Hi, I want to debug a single .go file while performing stdin and stdout redirection to external text files. Using the legacy debug adapter, I can achieve this by specifying the corresponding dlvFlags:

{
    "name": "Go: Lauch file with redirection",
    "type": "go",
    "request": "launch",
    "mode": "debug",
    "program": "${file}",
    "cwd": "${fileDirname}",
    "debugAdapter": "legacy",
    "dlvFlags": [
        "-r",
        "stdin:${fileDirname}/input.txt",
        "-r",
        "stdout:${fileDirname}/output.txt"
    ]
}

However, if I try using the dlv-dap adapter, the redirection flags seem to be ignored. Is this expected behavior? Am I missing any extra settings to make this scenario work properly with the dlv-dap adapter?

For reference, I am using Go version 1.18 and vscode-go version 0.32.0, running on WSL2.

[polinasok]

we make dlv dap accepts -r flags and use them for the future request. (drawback: the concept doesn't map cleanly imo)

Why doesn't this map cleanly? We talked about this a while back offline and my notes say to just pass the command-line input via debugger.Config in commands.go

[hyangah]

Unlike traditional dlv commands (debug, test, exec), dlv dap doesn't finalize what it will do until the launch request arrives. --redirect specifies the stdio used for a debug program. Thus, to me, it's like program or args attributes, or -wd flag. That's why I think the concept doesn't map cleanly.

On the other hand, I noticed https://github.com/go-delve/delve/issues/2329 is closed and the door to have a long running DAP server is officially shut. So maybe now, it doesn't matter 🤷.

BTW I thought we didn't examine this --redirect flag carefully since it was just added late 2020.

[polinasok]

I see what you mean. We did this mental exercise with --backend (#1591). Consistency has its advantages although the users would see no difference unless they run dlv dap manually. It would be more code (compare #2567 to https://github.com/go-delve/delve/pull/2965), and we also need a new attribute in package.json (unlike backend, which already existed). What about https://github.com/go-delve/delve/pull/2965? Do you think --disable-aslr Disables address space randomization should be handled the same way?

[hyangah]

I think --disable-aslr is in a similar category that affects only a subset of possible launch configuration. As you reported in https://github.com/go-delve/delve/issues/2361, dlv's flag scope handling isn't ideal either. I think --disable-aslr is currently a rarely used feature, so I think whatever easier to implement is good.

Redirection of stdin/stdout/stderr can be more frequently used (again, it's like args, isn't it?), so I think they eventually deserves designated attribute(s) in a launch configuration than the grab bag dlvFlags. But if the delve side change is too difficult (adding a new attribute in package.json isn't difficult btw), I am fine with just going with the global --redirect flag.

Q. The extension doesn't interpret the relative paths included in the flags. How will they be handled in delve? (program and args use the delve's working directory, which can be changed by dlvCwd.)