Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

need to debug embedded Go #873

Open
am21 opened this issue Jun 12, 2017 · 6 comments
Open

need to debug embedded Go #873

am21 opened this issue Jun 12, 2017 · 6 comments

Comments

@am21
Copy link

am21 commented Jun 12, 2017

Hi,

I need to debug a Go application that has to reside in a DLL. In order to have the DLL loading work properly, I had to write a small C layer on top of Go.
How can I get dlv to attach to the Go code? Example code to reproduce my steps is at https://groups.google.com/d/msg/golang-nuts/ywzTYaalWLE/kn4GoobJAAAJ.

@aarzilli
Copy link
Member

What @alexbrainman told you is 100% correct, what you want to debug is not a go program and delve does not work if the program isn't a go program. It is possible, in theory, to get delve there but it's a huge change.
Honestly I'm not even sure how your approach there is even working. What's initializing go's runtime? What happens if you try to start a goroutine?

@am21
Copy link
Author

am21 commented Jun 12, 2017

I added a simple goroutine call in sayhello(), and it seems it's running properly. I'm not sure about Go runtime initialization, but gdb shows a number of threads starting, I assumed it was related to Go's runtime.

Starting program: C:\Users\amellan\src\ngm\examples\sharedlib\dload.exe
[New Thread 17104.0x4350]
[New Thread 17104.0x4a50]
[New Thread 17104.0x23a4]
[New Thread 17104.0x2dc4]
[New Thread 17104.0x42f8]
[New Thread 17104.0x4d50]
[New Thread 17104.0x4c]
[New Thread 17104.0x2ad0]
Hello!
hello goroutine

Goodbye
[Thread 17104.0x42f8 exited with code 0]
[Thread 17104.0x4c exited with code 0]
[Thread 17104.0x4d50 exited with code 0]
[Thread 17104.0x2ad0 exited with code 0]
[Thread 17104.0x23a4 exited with code 0]
[Thread 17104.0x4a50 exited with code 0]
[Thread 17104.0x2dc4 exited with code 0]
[Inferior 1 (process 17104) exited normally]

I assume the issue is exactly the same with a .so on Linux? go build -buidmode=c-shared is supposed to work on Linux, not sure if it would really change the problem.

@aarzilli
Copy link
Member

Probably not, I don't know.

@am21
Copy link
Author

am21 commented Jun 12, 2017

Based on the documentation from go build -buildmode=c-archive, I assume go takes care of the proper initialization:

  -buildmode=c-archive
	Build the listed main package, plus all packages it imports,
	into a C archive file. The only callable symbols will be those
	functions exported using a cgo //export comment. Requires
	exactly one main package to be listed.

@antJack
Copy link

antJack commented Mar 23, 2021

still unable to debug embedded Go? or are there any solutions?

@Robert-M-Muench
Copy link

Looks like debugging embedded Go is still not possible.

Every Go main package can be built as a C shared library. The runtime initialization works and is done at DLL load time. Thereafter, things like goroutines can be used.

I think what's needed is some way to trigger Delve from the Go code. Something like a break into debugger function.

The other option that comes to mind is, to call a function that gets the DLL into a state that gops can detect it. But I don't have any idea how gops works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants