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.

Comment 2:

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

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)

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.

Comment 5 by cgmurray:

Thanks, will do!

Comment 6:

Not a 1.1 blocker.

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

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.

Comment 8:

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

Labels changed: added go1.1.

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.

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]"

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.

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.

Comment 13:

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

Comment 14:

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

Comment 15:

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

Status changed to Started.

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

Comment 17:

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

Comment 18:

Labels changed: added feature.

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?

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.

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.

Comment 22:

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

Comment 23:

Labels changed: removed feature.

Comment 24:

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

Comment 25:

Labels changed: added repo-main.

Comment 26:

Labels changed: added gdb.