Re: [go-nuts] How to debug/trace code?

[Nate Finch]

I'm pretty sure there's a good extension for intellij but I don't know anything about it. Google is your friend here I think.

On Mar 20, 2013 7:34 PM, <sahme...@gmail.com> wrote:

I have intelliJ idea 11, and I was wondering if I could somehow put breakpoints in a go program and go through the execution of some program?

I'm not sure if there is a IDE of choice yet in the community so not sure what is possible at this point.

Comments?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Péter Szilágyi]

Hi

  If you're using https://github.com/mtoader/google-go-lang-idea-plugin, them I'm afraid I haven't found any mention of debugging support on the site (nor am able to do on my install). Eventually you can file an issue and ask whether and when they will support it.

  Btw, I found the idea plugin nice, but it would need quite some community effort to get all the missing features in. On others I cannot comment.

Cheers,

  Peter

[Steve McCoy]

Go programs at least work well in gdb. I know there's an IntelliJ C and C++ plugin that uses gdb behind its debugger interface — if there's a Go plugin out there, it probably does something similar.

On Friday, March 22, 2013 8:51:12 PM UTC-4, gitted wrote:

So other than that the only option is print statements then?

Isn't being able to debug/trace through the execution kind of a top priority?  

[rocky]

On Friday, March 22, 2013 8:51:12 PM UTC-4, gitted wrote:

So other than that the only option is print statements then?

Isn't being able to debug/trace through the execution kind of a top priority?

I've been thinking about approaches to writing a debugger for go.

As was mentioned, there is coming at it from the gdb side. But with a language like go, I think one would want to switch to using more go than C where possible.

As venerable as gdb is, I suspect -- implementation wise -- it could be improved upon.

And what about code produced by the non-gcc compiler?  What information is there available about the run-time structures that are available in the non-gcc compiler?

On GNU/Linux running "file" on a go-produced ".a" file reports: "current ar archive random library". Binaries on GNU/Linux seem to be ELF format, statically linked and not stripped.
 
I'm sure there has to at least be some sort of line/instruction offset table since that's often used in just reporting run-time errors, and strings shows that there is variable name information, although I'm not sure if the types are recorded in there by default.

Since go compiles lightening fast, I've also been thinking about some sort of hybrid approach: on the fly parts could get compiled, not for running the code part per se, but to create additional information used in debugging. For example more detailed position information. For compiling source on the fly, what I'd like to see is some sort of SHA1 or checksum stored in the executable so that we can verify that the source we think we have matches the source used in compilation.

Information gathered might be useful in this recompilation might also be useful in hooking into d-trace-like interception of calls and returns, assuming enough desired information isn't already around at run time.

Anyone care to share their thoughts on writing a debugger?

[minux]

On Sat, Mar 23, 2013 at 7:54 PM, <misc...@offblast.org> wrote:
> What ever happened to acid?
> http://doc.cat-v.org/plan_9/4th_edition/papers/acidpaper
i think some people (even some from the Go team) still use acid.

for example, i remembered that some time ago, an Go issue had
something to do with a freebsd coredump file, so Russ implemented
reading freebsd coredumps in plan9port's libmach, and hence acid,
and then used acid to find the cause of the problem.

of course it's also possible to use acid to debug Go programs on
some platforms (mainly linux and darwin, where plan9port supports
best)

[minux]

On Sat, Mar 23, 2013 at 1:34 PM, rocky <rocky.b...@gmail.com> wrote:
> I've been thinking about approaches to writing a debugger for go.

if you want to do that, i can think of two main approaches here:
1. implement a Go interpreter so debugging is easy
2. run Go natively, and leverage OS-specific way to control the process

if you choose the 2nd route, you will have to implement a lot of things just
to set breakpoints, and generally, it doesn't worth the effort.

> As was mentioned, there is coming at it from the gdb side. But with a
> language like go, I think one would want to switch to using more go than C
> where possible.
>
> As venerable as gdb is, I suspect -- implementation wise -- it could be
> improved upon.

you're welcomed to help with the Go gdb plugin written in Python.

> And what about code produced by the non-gcc compiler? What information is
> there available about the run-time structures that are available in the
> non-gcc compiler?

the gc toolchain support generating DWARF debugging information, so in
theory, most of the required information is there (the main lacking bits is
registeration info).

> On GNU/Linux running "file" on a go-produced ".a" file reports: "current ar
> archive random library". Binaries on GNU/Linux seem to be ELF format,
> statically linked and not stripped.

Gc's .a file is an archive file, but its object files are not normal
object files.
they contain symbolic pseudo assembly generated by the compiler.
the final assembly step is produced by the linker.

> I'm sure there has to at least be some sort of line/instruction offset table
> since that's often used in just reporting run-time errors, and strings shows
> that there is variable name information, although I'm not sure if the types
> are recorded in there by default.

the symbolic assembly (object files) contains full typing information for Go
programs (to facilitate DWARF generation).

> Since go compiles lightening fast, I've also been thinking about some sort
> of hybrid approach: on the fly parts could get compiled, not for running the
> code part per se, but to create additional information used in debugging.

could you please give more details on this? i don't understand that, are
you suggesting that we embed a part of the toolchain into the binary produced
by gc and then generating program segments on the fly??

> For example more detailed position information. For compiling source on the
> fly, what I'd like to see is some sort of SHA1 or checksum stored in the
> executable so that we can verify that the source we think we have matches
> the source used in compilation.

This is unrelated to the debugging problem.

> Information gathered might be useful in this recompilation might also be
> useful in hooking into d-trace-like interception of calls and returns,
> assuming enough desired information isn't already around at run time.

i think enough information is retained in the binary for intercepting calls and
returns.

[Joe Poirier]

On Wednesday, March 20, 2013 6:34:48 PM UTC-5, gitted wrote:

I have intelliJ idea 11, and I was wondering if I could somehow put breakpoints in a go program and go through the execution of some program?

I'm not sure if there is a IDE of choice yet in the community so not sure what is possible at this point.

Comments?

Affinic (http://www.affinic.com/?page_id=109) has a free gdb (Qt ?) front-end that runs on Windows, Linux, and OSX. I used on OSX once to run through a Go program and it worked without any problems.  

[Dobrosław Żybort]

LiteIDE have build in Go debugger
http://code.google.com/p/golangide/

[Rocky Bernstein]

I'll try to use the traditional C,  gcc, gdb pattern as an example. Here in order to debug code you must have had to set debug flags in the compilation. Further more binaries can be stripped.

But sometimes what happens is there is code that is already built, it  runs and then sometime later you find you have a problem. You could go  back and recompile bits and pieces of this and then rerun to try to get to the point of the problem  However in a more enlightened system what one would like to do is pseudo-recompile not for the purpose of producing new code, but just the symbol table information. 

 

i don't understand that, are
you suggesting that we embed a part of the toolchain into the binary produced
by gc and then generating program segments on the fly??

> For example more detailed position information. For compiling source on the
> fly, what I'd like to see is some sort of SHA1 or checksum stored in the
> executable so that we can verify that the source we think we have matches
> the source used in compilation.

This is unrelated to the debugging problem.

To the extent that debuggers show source text, it is not. 

Debuggers show source code in some sort of text format. Compiler don't run that directly although text was used at some point to produce the code it is running. There should be a way to ensure that the source text that a debugger or front-end GUI is showing you matches the same source that was used in the compilation. 

In practice what's done is hope that whenever you find a file name that has the same name as  that which the run-time reports, it must be the source as was used in compilation. Or hopefully something close to that. 

File contents change over time, they can move around too. And what is often recorded in the object may not be an absolute file name, but rather some sort of short name or relative path. To make things even more complicated, one might be running the front-end debugger interface on a computer that is not the same place as where the code is running. Here the likelihood is even greater that the source that is shown is a copy of what was used in compilation and that there may be variation between the two. 

gdb has for example a "dir" command to try to negotiate these differences. All of this is a bit more ad hoc than using say a SHA1 or checksum for file contents in order to verify the 

[Rocky Bernstein]

Thanks, everyone, for the pointers.

--

You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/ujoj9Reu29A/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.