[Bug go/64595] New: cgo installed into wrong directory

[Bug go/64595] New: cgo installed into wrong directory

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

            Bug ID: 64595
           Summary: cgo installed into wrong directory
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: rguenth at gcc dot gnu.org
                CC: cmang at google dot com

With --enable-version-specific-runtime-libs I get go and gofmt installed in
$prefix/bin but cgo is installed into $prefix/lib/gcc/$target/$version/cgo

That is inconsistent.

>From the install log:

[ 4801s] test -z "/usr/bin" || /usr/bin/mkdir -p
"/home/abuild/rpmbuild/BUILDROOT/gcc5-5.0.0+r219531-0.x86_64/usr/bin"
[ 4801s]   /usr/bin/install -c go
'/home/abuild/rpmbuild/BUILDROOT/gcc5-5.0.0+r219531-0.x86_64/usr/bin/./go-5'
[ 4801s]   /usr/bin/install -c gofmt
'/home/abuild/rpmbuild/BUILDROOT/gcc5-5.0.0+r219531-0.x86_64/usr/bin/./gofmt-5'
[ 4801s] test -z "/usr/lib64/gcc/x86_64-suse-linux/5" || /usr/bin/mkdir -p
"/home/abuild/rpmbuild/BUILDROOT/gcc5-5.0.0+r219531-0.x86_64/usr/lib64/gcc/x86_64-suse-linux/5"
[ 4801s]   /usr/bin/install -c cgo
'/home/abuild/rpmbuild/BUILDROOT/gcc5-5.0.0+r219531-0.x86_64/usr/lib64/gcc/x86_64-suse-linux/5/./cgo-5'

that is, why

bin_PROGRAMS = go$(EXEEXT) gofmt$(EXEEXT)
libexecsub_PROGRAMS = cgo$(EXEEXT)

?

There are also no manual pages or other documentation about these tools it
seems.

[Bug go/64595] cgo installed into wrong directory

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
According to http://golang.org/cmd/cgo/ cgo isn't supposed to be called
directly, but only via go tool cgo.  But the version suffix will probably break
it.

[Bug go/64595] cgo installed into wrong directory

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #2 from Ian Lance Taylor <ian at airs dot com> ---
Right, cgo is not run directly.  It is run by the go tool.  It is in effect an
internal program like cc1.

The version suffix should be fine if libexecsubdir in libgo matches
libexecsubdir in gotools, as the go tool will locate cgo via the variable
theGccgoToolDir written to version.go by libgo/Makefile.  I'll see if that
works with --enable-versions-specific-runtime-libs.

The docs are online at http://golang.org/cmd/{go,gofmt,cgo} which is where most
people read them.    The docs come from the program source
(libgo/go/cmd/*/doc.go).  The programs also have -help options.  Would you like
me to add small man pages that direct people to the web pages?

[Bug go/64595] cgo installed into wrong directory

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 14 Jan 2015, ian at airs dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
> 
> --- Comment #2 from Ian Lance Taylor <ian at airs dot com> ---
> Right, cgo is not run directly.  It is run by the go tool.  It is in effect an
> internal program like cc1.

Ah - the README didn't say that.

> The version suffix should be fine if libexecsubdir in libgo matches
> libexecsubdir in gotools, as the go tool will locate cgo via the variable
> theGccgoToolDir written to version.go by libgo/Makefile.  I'll see if that
> works with --enable-versions-specific-runtime-libs.

Any example use that will end up executing cgo so I can check it out 
locally?

> The docs are online at http://golang.org/cmd/{go,gofmt,cgo} which is where most
> people read them.    The docs come from the program source
> (libgo/go/cmd/*/doc.go).  The programs also have -help options.  Would you like
> me to add small man pages that direct people to the web pages?

Yes, that would be convenient!  (obviously cgo doesn't need a manpage 
then)

[Bug go/64595] cgo installed into wrong directory

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #4 from Ian Lance Taylor <ian at airs dot com> ---
To invoke cgo, put this code in a file foo.go and type "go run foo.go" (or "go
build foo.go && ./foo").


package main

// #include <stdio.h>
// void cprintln(const char *s) { puts(s); }
import "C"

func main() {
    C.cprintln(C.CString("Hello, world"))
}

[Bug go/64595] cgo installed into wrong directory

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 14 Jan 2015, ian at airs dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
> 
> --- Comment #4 from Ian Lance Taylor <ian at airs dot com> ---
> To invoke cgo, put this code in a file foo.go and type "go run foo.go" (or "go
> build foo.go && ./foo").
> 
> 
> package main
> 
> // #include <stdio.h>
> // void cprintln(const char *s) { puts(s); }
> import "C"
> 
> func main() {
>     C.cprintln(C.CString("Hello, world"))
> }

Hmm, I get

> go-5 build foo.go 
no debug info in ELF executable errno -1
fatal error: no debug info in ELF executable

runtime stack:
no debug info in ELF executable errno -1
panic during panic

runtime stack:
no debug info in ELF executable errno -1
stack trace unavailable

(not really informative, seems to be from the go-5 binary).  On
openSUSE all binaries have debug information stripped and put
into separate objects not necessarily installed.  Installing it
doesn't solve the above issue.  The message seems to originate
from libbacktrace (unwind information is not stripped, obviously).

> readelf -S /usr/bin/go-5
There are 33 section headers, starting at offset 0x70ad10:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .interp           PROGBITS         0000000000400270  00000270
       000000000000001c  0000000000000000   A       0     0     1
  [ 2] .note.ABI-tag     NOTE             000000000040028c  0000028c
       0000000000000020  0000000000000000   A       0     0     4
  [ 3] .note.gnu.build-i NOTE             00000000004002ac  000002ac
       0000000000000024  0000000000000000   A       0     0     4
  [ 4] .hash             HASH             00000000004002d0  000002d0
       0000000000000704  0000000000000004   A       6     0     8
  [ 5] .gnu.hash         GNU_HASH         00000000004009d8  000009d8
       000000000000001c  0000000000000000   A       6     0     8
  [ 6] .dynsym           DYNSYM           00000000004009f8  000009f8
       0000000000001770  0000000000000018   A       7     1     8
  [ 7] .dynstr           STRTAB           0000000000402168  00002168
       000000000000093f  0000000000000000   A       0     0     1
  [ 8] .gnu.version      VERSYM           0000000000402aa8  00002aa8
       00000000000001f4  0000000000000002   A       6     0     2
  [ 9] .gnu.version_r    VERNEED          0000000000402ca0  00002ca0
       0000000000000120  0000000000000000   A       7     4     8
  [10] .rela.dyn         RELA             0000000000402dc0  00002dc0
       0000000000000048  0000000000000018   A       6     0     8
  [11] .rela.plt         RELA             0000000000402e08  00002e08
       00000000000016f8  0000000000000018   A       6    13     8
  [12] .init             PROGBITS         0000000000404500  00004500
       000000000000001a  0000000000000000  AX       0     0     4
  [13] .plt              PROGBITS         0000000000404520  00004520
       0000000000000f60  0000000000000010  AX       0     0     16
  [14] .text             PROGBITS         0000000000405480  00005480
       000000000029fc34  0000000000000000  AX       0     0     16
  [15] .fini             PROGBITS         00000000006a50b4  002a50b4
       0000000000000009  0000000000000000  AX       0     0     4
  [16] .rodata           PROGBITS         00000000006a50c0  002a50c0
       00000000002b30b0  0000000000000000   A       0     0     32
  [17] .eh_frame_hdr     PROGBITS         0000000000958170  00558170
       000000000000ea8c  0000000000000000   A       0     0     4
  [18] .eh_frame         PROGBITS         0000000000966c00  00566c00
       0000000000072dc4  0000000000000000   A       0     0     8
  [19] .gcc_except_table PROGBITS         00000000009d99c4  005d99c4
       0000000000004849  0000000000000000   A       0     0     4
  [20] .tbss             NOBITS           0000000000bdec40  005dec40
       00000000000000d8  0000000000000000 WAT       0     0     8
  [21] .init_array       INIT_ARRAY       0000000000bdec40  005dec40
       0000000000000018  0000000000000000  WA       0     0     8
  [22] .fini_array       FINI_ARRAY       0000000000bdec58  005dec58
       0000000000000008  0000000000000000  WA       0     0     8
  [23] .jcr              PROGBITS         0000000000bdec60  005dec60
       0000000000000008  0000000000000000  WA       0     0     8
  [24] .data.rel.ro      PROGBITS         0000000000bdec80  005dec80
       0000000000000148  0000000000000000  WA       0     0     32
  [25] .dynamic          DYNAMIC          0000000000bdedc8  005dedc8
       0000000000000210  0000000000000010  WA       7     0     8
  [26] .got              PROGBITS         0000000000bdefd8  005defd8
       0000000000000018  0000000000000008  WA       0     0     8
  [27] .got.plt          PROGBITS         0000000000bdf000  005df000
       00000000000007c0  0000000000000008  WA       0     0     8
  [28] .data             PROGBITS         0000000000bdf7c0  005df7c0
       000000000007e170  0000000000000000  WA       0     0     32
  [29] .bss              NOBITS           0000000000c5d940  0065d930
       0000000000024a10  0000000000000000  WA       0     0     32
  [30] .go_export        PROGBITS         0000000000000000  0065d930
       00000000000ad29e  0000000000000000           0     0     1
  [31] .gnu_debuglink    PROGBITS         0000000000000000  0070abce
       0000000000000010  0000000000000000           0     0     1
  [32] .shstrtab         STRTAB           0000000000000000  0070abde
       000000000000012e  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

If I build

package main
func main() {
}

with gccgo, strip it and then try to execute it the same error appears:

rguenther@murzim:/tmp> gccgo-5 foo.go 
rguenther@murzim:/tmp> > ./a.out 
rguenther@murzim:/tmp> gccgo-5 foo.go 
rguenther@murzim:/tmp> ./a.out 
rguenther@murzim:/tmp> strip a.out
rguenther@murzim:/tmp> ./a.out 
no debug info in ELF executable errno -1
fatal error: no debug info in ELF executable

runtime stack:
no debug info in ELF executable errno -1
panic during panic

runtime stack:
no debug info in ELF executable errno -1
stack trace unavailable


what's the reason for this?

[Bug go/64595] cgo installed into wrong directory

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
The backtrace is

Breakpoint 1, __GI_exit (status=4) at exit.c:104
104     exit.c: No such file or directory.
(gdb) up
#1  0x00007ffff731a52f in runtime_startpanic () from /usr/lib64/libgo.so.7
(gdb) 
#2  0x00007ffff731a617 in runtime_throw () from /usr/lib64/libgo.so.7
(gdb) 
...
#24 0x00007ffff7646311 in ?? () from /usr/lib64/libgo.so.7
(gdb) 
#25 0x00007ffff664ba79 in _Unwind_Backtrace () from /lib64/libgcc_s.so.1
(gdb) 
#26 0x00007ffff7646365 in backtrace_full () from /usr/lib64/libgo.so.7
(gdb) 
#27 0x00007ffff730b899 in runtime_callers () from /usr/lib64/libgo.so.7
(gdb) 
#28 0x00007ffff732676a in runtime_MProf_Malloc () from /usr/lib64/libgo.so.7
(gdb) 
#29 0x00007ffff7324cde in runtime_mallocgc () from /usr/lib64/libgo.so.7
(gdb) 
#30 0x00007ffff7325772 in runtime_mallocinit () from /usr/lib64/libgo.so.7
(gdb) 
#31 0x00007ffff731d10b in runtime_schedinit () from /usr/lib64/libgo.so.7
(gdb) 
#32 0x00000000004014d1 in ?? ()
(gdb) 
#33 0x00007ffff62aebe5 in __libc_start_main (main=0x4014a0, argc=1, 
    argv=0x7fffffffdf08, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fffffffdef8) at libc-start.c:269
269     libc-start.c: No such file or directory.

[Bug go/64595] cgo installed into wrong directory

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #7 from Ian Lance Taylor <ian at airs dot com> ---
That failure is not related to the new gotools.  I expect it would happen with
any Go program.  Go requires that there be enough debug info to do a stack
backtrace with file/line information.  It uses the libbacktrace library, but
that library doesn't understand separate debuginfo sections.

I can fix this specific problem so that the program is more likely to run, but
in general Go code expects to be able to get that backtrace and most real Go
programs will fail without it.

I guess I or somebody needs to fix libbacktrace to understand separate
debuginfo objects.

[Bug go/64595] cgo installed into wrong directory

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #8 from Andreas Schwab <schwab@linux-m68k.org> ---
Why does libbacktrace need debug info?  All required unwind information is
included in the binary.  Glibc's backtrace can do that too.

[Bug go/64595] cgo installed into wrong directory

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #8)
> Why does libbacktrace need debug info?  All required unwind information is
> included in the binary.  Glibc's backtrace can do that too.

Most likely the same reason why Java needs it.  So it can see if the file that
the backtrace is coming from is a system library or not.

[Bug go/64595] cgo installed into wrong directory

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #10 from Ian Lance Taylor <ian at airs dot com> ---
The point of libbacktrace, at least if you call the backtrace_full function, is
to get file/line information.  If you don't need file/line information, you can
just use _Unwind_Backtrace.

[Bug go/64595] cgo installed into wrong directory

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #11 from Andreas Schwab <schwab@linux-m68k.org> ---
But it shouldn't crash the app if you don't have the full information.

[Bug go/64595] cgo installed into wrong directory

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #12 from Ian Lance Taylor <ian at airs dot com> ---
It's not libbacktrace that is crashing the app, it's libgo.

And, yes, probably libgo should not crash the app either.  But it's also true
that many Go programs simply won't work correctly if file/line information is
not available.

[Bug go/64595] cgo installed into wrong directory

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 19 Jan 2015, ian at airs dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
> 
> --- Comment #7 from Ian Lance Taylor <ian at airs dot com> ---
> That failure is not related to the new gotools.  I expect it would happen with
> any Go program.  Go requires that there be enough debug info to do a stack
> backtrace with file/line information.  It uses the libbacktrace library, but
> that library doesn't understand separate debuginfo sections.
> 
> I can fix this specific problem so that the program is more likely to run, but
> in general Go code expects to be able to get that backtrace and most real Go
> programs will fail without it.
> 
> I guess I or somebody needs to fix libbacktrace to understand separate
> debuginfo objects.

Note that then gccgo should automatically enable -g, no?  Because
the only debuginfo present in a.out when compiling with gccgo is
that of the crt?.o files.  (yes, libgo is also stripped).

[Bug go/64595] cgo installed into wrong directory

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 20 Jan 2015, ian at airs dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
> 
> --- Comment #12 from Ian Lance Taylor <ian at airs dot com> ---
> It's not libbacktrace that is crashing the app, it's libgo.
> 
> And, yes, probably libgo should not crash the app either.  But it's also true
> that many Go programs simply won't work correctly if file/line information is
> not available.

Why?  I can't think of any good reason to require file/line information
for backtraces in a regular program.

[Bug go/64595] cgo installed into wrong directory

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So do you only need .debug_line and some minimal .debug_info, or would
.debug_line be enough?
gdb understands e.g. .gnu_debuginfo format
http://fedoraproject.org/wiki/Features/MiniDebugInfo
which is essentially .xz compressed ELF in a section, containing just
.symtab/.strtab/.shstrtab.  The wiki page says optionally .debug_line, but I
haven't found how that is produced.  So perhaps you should produce something
like that for go binaries?  Or just hack up dwarf2out.c, so in addition to
.debug_* sections it emits .gnu.go.debug_{line,abbrev,info} where the info
would only contain the absolute minimum of DWARF DIEs and attributes needed to
locate debug_line and find the ranges.  Not being able to strip large debuginfo
sounds like a serious problem to me.

[Bug go/64595] go programs abort when debug info is stripped

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #16 from Ian Lance Taylor <ian at airs dot com> ---
Yes, gccgo ought to enable -g by default.  For some reason I thought it did but
clearly I was wrong.

file/line info is needed for the standard library runtime.Callers function,
which is used by many other packages like the log and testing packages. 
Basically Go code assumes that you can always find out who is calling you. 
It's not C.

The Go library only needs whatever libbacktrace needs.  Right now I think that
is a minimal .debug_info, a corresponding .debug_abbrev, a full .debug_line,
possibly .debug_ranges, possibly .debug_str.  I think there is a Google
internal patch to generate this (though Go doesn't use it internally either). 
I can try to dig that up but it seems like stage 1 material.

[Bug go/64595] go programs abort when debug info is stripped

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Ian Lance Taylor from comment #16)
> Yes, gccgo ought to enable -g by default.  For some reason I thought it did
> but clearly I was wrong.

Maybe -g1 is enough now.

[Bug go/64595] go programs abort when debug info is stripped

[ian at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #18 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> ---
Author: ian
Date: Fri Jan 23 01:42:08 2015
New Revision: 220022

URL: https://gcc.gnu.org/viewcvs?rev=220022&root=gcc&view=rev
Log:
    PR go/64595
    * go.1, gofmt.1: New files.
    * Makefile.am (man_MANS): New variable.
    * Makefile.in: Rebuild.

Added:
    trunk/gotools/go.1
    trunk/gotools/gofmt.1
Modified:
    trunk/gotools/ChangeLog
    trunk/gotools/Makefile.am
    trunk/gotools/Makefile.in

[Bug go/64595] go programs abort when debug info is stripped

[ian at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #19 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> ---
Author: ian
Date: Fri Jan 23 19:49:53 2015
New Revision: 220057

URL: https://gcc.gnu.org/viewcvs?rev=220057&root=gcc&view=rev
Log:
    PR go/64595
runtime: Don't crash in runtime_callers if no debug info available.

Modified:
    trunk/libgo/runtime/go-callers.c

[Bug go/64595] go programs abort when debug info is stripped

[ian at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

--- Comment #20 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> ---
Author: ian
Date: Fri Jan 23 22:26:41 2015
New Revision: 220064

URL: https://gcc.gnu.org/viewcvs?rev=220064&root=gcc&view=rev
Log:
    PR go/64595
    * go-lang.c (go_langhook_init_options_struct): Set default
    debug_info_level.
    (go_langhook_post_options): If debug_info_level is still the
    default, make sure write_symbols is set.
    * gccgo.texi (Invoking gccgo): Document that -g1 is the default.

Modified:
    trunk/gcc/go/ChangeLog
    trunk/gcc/go/gccgo.texi
    trunk/gcc/go/go-lang.c

[Bug go/64595] go programs abort when debug info is stripped

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #21 from Ian Lance Taylor <ian at airs dot com> ---
I think all the issues raised in this bug report are now addressed.

[Bug go/64595] go programs abort when debug info is stripped

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |allan at archlinux dot org

--- Comment #22 from Ian Lance Taylor <ian at airs dot com> ---
*** Bug 57194 has been marked as a duplicate of this bug. ***