This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Golang debugging issues
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Derek Parker <derek at hashrocket dot com>
- Cc: Patrick Macdonald <patrickm at redhat dot com>, gdb at sourceware dot org
- Date: Fri, 27 Mar 2015 14:35:07 +0100
- Subject: Re: Golang debugging issues
- Authentication-results: sourceware.org; auth=none
- References: <CALFgRJOSZHR4U0-hfL5zHZWvv0C2VUNv0xuU37k0pZDUy54cuA at mail dot gmail dot com> <55153B63 dot 2080504 at redhat dot com>
Hello Derek,
> My name is Derek and I’ve been working on Delve. I got a link to
> https://sourceware.org/gdb/wiki/GoDebugging
I am maintaining that page.
> Delve is pre 1.0 and under heavy, active development, with some
> pretty big improvements making their way into master soon. I’d
> really like to hear your thoughts regarding shortcomings of current
> debuggers with regard to Go.
The problem with debugging Go is its incorrect+incomplete DWARF. That needs
to be fixed in golang, I do not see anything missing in GDB if golang has been
producing debug info correctly.
gccgo produces more correct DWARF - or at least the missing parts would be
easier to fix than the incorrect+missing parts from golang - but for some
reason developers in Go language insist on using golang. I heard golang
produces more effective real world binaries (despite synthetic benchmarks
I have seen performed better in gccgo) because of better variable escape
optimizations - common with all the variable bindings in Go functions.
The language of the debugger is unrelated to the language it is debugging.
We can discuss whether GDB is the right debugger in general but then there is
also LLDB to consider.
So I am curious what features should Delve provide which GDB does not.
And if there are any why it isn't easier to script them in Python for GDB
instead of writing a new debugger from scratch.
Regards,
Jan