cmd/link: support gdb debugging when hostlinking

[DanielMorsing]

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]

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]

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]

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]

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]

Comment 5 by cgmurray:

Thanks, will do!

[adg]

Comment 6:

Not a 1.1 blocker.

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

[ianlancetaylor]

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]

Comment 8:

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

Labels changed: added go1.1.

[DanielMorsing]

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]

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]

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]

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]

Comment 13:

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

[dsymonds]

Comment 14:

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

[ianlancetaylor]

Comment 15:

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

Status changed to Started.