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

cmd/link: support gdb debugging when hostlinking #5221

Open
DanielMorsing opened this Issue Apr 5, 2013 · 26 comments

Comments

Projects
None yet
10 participants
@DanielMorsing
Contributor

DanielMorsing commented Apr 5, 2013

When linking with the host linker, the .debug_gdb_scripts symbol isn't emitted, causing
the gdb python script to not be loaded.

It appears that this isn't the only problem since manually loading the script throws the
following error:

Loading Go Runtime support.
Traceback (most recent call last):
  File "../go/src/pkg/runtime/runtime-gdb.py", line 198, in <module>
    _rctp_type = gdb.lookup_type("struct runtime.rtype").pointer()
gdb.error: No struct type named runtime.rtype.
@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Apr 5, 2013

Comment 1:

I don't know if we can fix this for Go 1.1 but it would be great if somebody could take
a look.  I expect that we just need to emit an appropriate section into the go.o file
generated by 6l before invoking gcc.  And we need to find out why the script doesn't
load properly.

Labels changed: added go1.1.

@DanielMorsing

This comment has been minimized.

Contributor

DanielMorsing commented Apr 5, 2013

Comment 2:

Running gdb and typing "info types" doesn't show any go types, so that's probably why
it's not loading properly.
@gopherbot

This comment has been minimized.

gopherbot commented Apr 9, 2013

Comment 3 by cgmurray:

I have a similar problem with cgo-programs but without the host linker enabled. When
running go build -x the last link step invokes "6l".
os: osx 10.7.5
go: go version devel +1a196137ed09 Tue Apr 09 18:17:55 2013 +1000 darwin/amd64
gdb: 7.5 (compiled "manually")
Steps to repro:
1. go tool cgo main.go && go build
2. gdb testcgo
Output:
BFD: /private/tmp/testcgo/testcgo: unknown load command 0x29
BFD: /private/tmp/testcgo/testcgo: unknown load command 0x29
Reading symbols from /private/tmp/testcgo/testcgo...
warning:
`/var/folders/73/ysvvspl16bj3pqjvyt5wr3cc0000gn/T/go-build152876071/_/tmp/testcgo/_obj/main.cgo2.o':
can't open to read symbols: No such file or directory.
...
similar warning emitted for main.o, gcc_amd64.o, gcc_darwin_amd64.o, gcc_setenv.o and
gcc_util.o

Attachments:

  1. main.c (58 bytes)
  2. main.h (54 bytes)
  3. main.go (127 bytes)
@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Apr 9, 2013

Comment 4:

I believe that on OS X the system linker by default leaves the debug info in the .o
files and gdb fetches them from there.  That will work poorly with the go tool because
the go tool discards the .o files, hence the error message you are seeing.  I believe
this issue is unrelated to the main problem here.  If you can open a new issue for the
OS X specific problem, that would be helpful.  It would also be helpful if you could
look at the man page for the system linker and see if there is an option to tell it to
pull in debug info from .o files into the final executable.
@gopherbot

This comment has been minimized.

gopherbot commented Apr 9, 2013

Comment 5 by cgmurray:

Thanks, will do!
@adg

This comment has been minimized.

Contributor

adg commented Apr 9, 2013

Comment 6:

Not a 1.1 blocker.

Labels changed: added priority-soon, removed priority-triage, go1.1.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Apr 10, 2013

Comment 7:

I think this is somewhat important for 1.1.  Lots of Go programs use cgo.  With 1.0,
those programs could be debugged using gdb.  With 1.1, they can not.  This is a
significant regression for a common case.
If it's too hard to fix then it's too hard to fix, but let's at least take the time to
understand how hard it is to fix.
@adg

This comment has been minimized.

Contributor

adg commented Apr 10, 2013

Comment 8:

Re-adding the label in the hope we can squash this before release.

Labels changed: added go1.1.

@DanielMorsing

This comment has been minimized.

Contributor

DanielMorsing commented Apr 10, 2013

Comment 9:

A good place to start would probably be here:
https://code.google.com/p/go/source/browse/src/cmd/ld/elf.c#1425
Not at a computer where I can test this, but I suspect it's just removing that
conditional.
@axw

This comment has been minimized.

Contributor

axw commented Apr 11, 2013

Comment 10:

I haven't looked into this deeply, but simply removing the conditional is not enough.
gdb says, "Reading symbols from
/home/awilkins/programming/go/src/github.com/pebbe/zmq2/version...DW_FORM_strp pointing
outside of .debug_str section [in module
/home/awilkins/programming/go/src/github.com/pebbe/zmq2/version]"
@axw

This comment has been minimized.

Contributor

axw commented Apr 19, 2013

Comment 11:

Had a bit more of a look. Bear in mind that I'm no DWARF expert my any stretch of the
imagination, so I could be full of crap.
It appears the problem (or at least the problem I noted above) is that no relocation
records are generated for .debug_info, .debug_abbrev, etc. If you move "go.o" so that
it's the first object in the linker args, the error message goes away because the
offsets are valid.
... however when I try to actually debug in gdb and hit a breakpoint, I now get a
SIGSEGV in _dl_fixup.
@minux

This comment has been minimized.

Member

minux commented Apr 19, 2013

Comment 12:

then it will be a big problem to fix, so I lowered the priority.
i think we don't have time to fix this before Go 1.1.

Labels changed: added priority-later, removed priority-soon.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Apr 20, 2013

Comment 13:

I have this mostly written for ELF.  I don't know if it will make it in for 1.1.
@dsymonds

This comment has been minimized.

Member

dsymonds commented Apr 26, 2013

Comment 14:

Labels changed: added go1.1maybe, removed go1.1.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Apr 29, 2013

Comment 15:

https://golang.org/cl/8858047/

Status changed to Started.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Apr 30, 2013

Comment 16:

This issue was updated by revision 825b1e1.

This CL is tested lightly on 386 and amd64 and fixes the cases
I tested.  I have not tested it on Darwin or Windows.
R=golang-dev, dave, daniel.morsing, rsc
CC=golang-dev
https://golang.org/cl/8858047
@robpike

This comment has been minimized.

Contributor

robpike commented May 18, 2013

Comment 17:

Labels changed: added go1.2maybe, removed go1.1maybe.

@rsc

This comment has been minimized.

Contributor

rsc commented Jul 30, 2013

Comment 18:

Labels changed: added feature.

@rsc

This comment has been minimized.

Contributor

rsc commented Aug 2, 2013

Comment 19:

Looks like Ian's CL fixed the difficult stuff. What's left is the .debug_gdb_scripts
symbol, right? I'm not sure how to do that. Maybe it suffices to put one in the .o file?
@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Aug 2, 2013

Comment 20:

I didn't test the DWARF reloc support on Darwin at all, I don't know that it works.
On Darwin the gdb scripts should be put into a section named "__debug_gdb_scri" in a
segment named __DWARF.  But that was only recently added to gdb, I don't know if it is
in a release yet at all.
@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Sep 6, 2013

Comment 21:

Not going to happen for 1.2.
This works on ELF based systems.  The issue remains open, or at any rate untested, for
Darwin.
It's not clear to me whether this will be an issue on Windows.  I guess it depends on
whether people use gdb with DWARF debug info on Windows.  As of this writing external
linking isn't implemented on Windows anyhow.

Labels changed: added go1.3maybe, removed go1.2maybe.

Status changed to Accepted.

@alexbrainman

This comment has been minimized.

Member

alexbrainman commented Sep 6, 2013

Comment 22:

Yes, people use gdb with DWARF debug info on Windows.
Alex
@rsc

This comment has been minimized.

Contributor

rsc commented Nov 27, 2013

Comment 23:

Labels changed: removed feature.

@rsc

This comment has been minimized.

Contributor

rsc commented Dec 4, 2013

Comment 24:

Labels changed: added release-none, removed go1.3maybe.

@rsc

This comment has been minimized.

Contributor

rsc commented Dec 4, 2013

Comment 25:

Labels changed: added repo-main.

@robpike

This comment has been minimized.

Contributor

robpike commented Mar 5, 2014

Comment 26:

Labels changed: added gdb.

@DanielMorsing DanielMorsing added the gdb label Mar 5, 2014

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc changed the title from cmd/ld: support gdb debugging when hostlinking to cmd/link: support gdb debugging when hostlinking Jun 8, 2015

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