Skip to content
This repository has been archived by the owner on Jul 15, 2023. It is now read-only.

Allow debugging of different files with main function from the same directory #1229

Closed
MZhoume opened this issue Sep 19, 2017 · 12 comments
Closed

Comments

@MZhoume
Copy link

MZhoume commented Sep 19, 2017

Thanks again for this amazing extension.

Regarding the debugging adapter, it would be nice to be able for us to debug a single .go file.

let dlvArgs = [mode || 'debug'];
if (mode === 'exec') {
	dlvArgs = dlvArgs.concat([program]);
}
dlvArgs = dlvArgs.concat(['--headless=true', '--listen=' + host + ':' + port.toString()]);
if (launchArgs.showLog) {
	dlvArgs = dlvArgs.concat(['--log=' + launchArgs.showLog.toString()]);
}
if (launchArgs.cwd) {
	dlvArgs = dlvArgs.concat(['--wd=' + launchArgs.cwd]);
}
if (launchArgs.buildFlags) {
	dlvArgs = dlvArgs.concat(['--build-flags=' + launchArgs.buildFlags]);
}
if (launchArgs.init) {
	dlvArgs = dlvArgs.concat(['--init=' + launchArgs.init]);
}
if (launchArgs.backend) {
	dlvArgs = dlvArgs.concat(['--backend=' + launchArgs.backend]);
}
if (launchArgs.args) {
	dlvArgs = dlvArgs.concat(['--', ...launchArgs.args]);
}

The program is only evaluated if the mode is set to exec, but not debug. However, delve supports debug specific file: del debug single.go.

Please let me know if that can be implemented. Thanks in advance!

@ramya-rao-a
Copy link
Contributor

When mode is not exec and the program points to a file and not directory, dlv debug is run on the parent directory of the file. Wont that work for your single file case?

@MZhoume
Copy link
Author

MZhoume commented Sep 20, 2017

@ramya-rao-a Thanks for your reply.

Unfortunately no. Let's think of a situation where we have a scripts folder for all the automation scripts. Each .go file should be able to run individually so they all are in the main package and with a main function. And you can just use go run script.go to run a single file.

Since they are all in the same folder, and the current delve debugger adapter does not support debugging single file. When debugging is needed, you will have to move the file to a different folder without any other go script in order for the debugger to work.

I am also taking this class where they put all the executable go files in one main folder (I assume it has something to do with the folder structure restriction go is enforcing). Not being able to debug only a single file make it impossible to work with the class assignments as well.

@ramya-rao-a
Copy link
Contributor

good point

@ramya-rao-a
Copy link
Contributor

@MZhoume I believe we need to check for the existence of the main function before running delve on the current file.

Take the case of a main package with multiple files. Only one of them will have the main function and I believe delve can only "run" the file with the main function and not the others.

Can you confirm?

@MZhoume
Copy link
Author

MZhoume commented Oct 20, 2017

@ramya-rao-a Yes, dlv run (now debug) can only runs on the files with main function defined.

However, dlv debug works with multiple files within the same main package as long as they have main function defined. (re-defined main function within the main package does not affect dlv command)

@ramya-rao-a
Copy link
Contributor

The simplest way to do this is to update https://github.com/Microsoft/vscode-go/blob/0.6.69/src/debugAdapter/goDebug.ts#L283 to replace the below

if (mode === 'exec') {
	dlvArgs = dlvArgs.concat([program]);
}

with

if (mode === 'exec' || (mode === 'debug' && !isProgramDirectory) ) {
	dlvArgs = dlvArgs.concat([program]);
}

The catch is that this will break the debugging feature for folks who have given file paths to the program attribute and started debugging from a file that does not have the main function.
They will either have to update their config to point program to the file directory or start debugging only from the file that has the main function.

To solve this, we will have to parse the file, and add the check for the main function in the above if condition.

PRs are welcome.

@chrislewisdev
Copy link

Hi @ramya-rao-a, I'm interested in working on this issue (although it could be a little stale now)!

I've had a look at the code and managed to set up my local environment for debugging the debugger. Thanks to your comments I have a good idea of the change I need to make to support this.

Currently, the way I'd like to perform the file-parsing to detect the existence of the main function is to use the existing goOutline functions, which should make it quite easy to see if a symbol for the main function is defined. However, goOutline has a dependency on the vscode namespace which I believe cannot be used in goDebug, meaning I'd need to do some refactoring to separate the two in order to use it.

Before I get too deep into refactoring, does this sound like an approach you'd support for a PR?

@ramya-rao-a
Copy link
Contributor

@chrislewisdev Yes, that sounds reasonable.

I would suggest not to try to refactor and re-use the code in goOutline. It has the use of tokens and a few other specific code that relies on the vscode namespace. Feel free to run cp.execFile directly in goDebug file to parse the file

@festo
Copy link

festo commented Feb 27, 2019

What is the status of this ticket? is there a plan to merge the PR soon?

@ramya-rao-a
Copy link
Contributor

@festo Please subscribe to the PR #2051 that is trying to address this issue and you will be notified of the updates.

@ramya-rao-a
Copy link
Contributor

To solve this, we will have to parse the file, and add the check for the main function in the above if condition.

Above was my conclusion in
#1229 (comment). We no longer want to go this route as it can get expensive to parse files.

Instead, below is the approach we would like to take to fix this issue:

  • When the program attribute points to a file, pass this file to the delve debug command instead of passing the import path to the package like we do today
  • When the program attribute points to a directory, we should do what we do today i.e pass the import path to the package to dlv debug
  • Update the default value for program attribute in goDebugConfiguration.ts file to be {$file} instead of ${fileDirname}

PRs are still welcome.
#2051 has been abandoned for now and therefore anyone else is most welcome to pick this one up

@ramya-rao-a ramya-rao-a changed the title Debug single file Allow debugging of different files with main function from the same directory Jul 7, 2019
hyangah added a commit to hyangah/vscode-go-old that referenced this issue Apr 13, 2020
When "Start Debugging" or "Run without Debugging" runs without
an explicit launch configuration (launch.json), we need to use
the directory of the file as the program. That is consistent
with the default GoDebugConfigurationProvider provides as the
default DebugConfigurations. (${fileDirname}).

Update microsoft#1229 and microsoft#3096
hyangah added a commit to hyangah/vscode-go-old that referenced this issue Apr 13, 2020
When "Start Debugging" or "Run without Debugging" runs without
an explicit launch configuration (launch.json), we need to use
the directory of the file as the program. That is consistent
with the default GoDebugConfigurationProvider provides as the
default DebugConfigurations. (${fileDirname}).

Update microsoft#1229 and microsoft#3096
ramya-rao-a pushed a commit that referenced this issue Apr 14, 2020
When "Start Debugging" or "Run without Debugging" runs without
an explicit launch configuration (launch.json), we need to use
the directory of the file as the program. That is consistent
with the default GoDebugConfigurationProvider provides as the
default DebugConfigurations. (${fileDirname}).

Update #1229 and #3096
@ramya-rao-a
Copy link
Contributor

The fix associated with this issue is now available in the latest version of the extension

When the program attribute in your debug configuration points to a file or ${file} for current file, the file in question will be passed to delve allowing you to debug even when multiple files in the same folder have the main() function

@vscodebot vscodebot bot locked and limited conversation to collaborators May 31, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants