[Bug go/61880] New: Linking with external functions in C does not work in GO when using gccgo, while it works in gc

[Bug go/61880] New: Linking with external functions in C does not work in GO when using gccgo, while it works in gc

[lists at kambanaria dot org]

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

            Bug ID: 61880
           Summary: Linking with external functions in C does not work in
                    GO when using gccgo, while it works in gc
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: lists at kambanaria dot org
                CC: cmang at google dot com

Created attachment 33173
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33173&action=edit
tiniest GOPATH demoing the problem (28 nonempty lines, 6 in C, 22 in GO
including comments)

This is continuation of issue reported here:
https://code.google.com/p/gofrontend/issues/detail?id=36

Since I have changed the test case to be extremely simple with no external
references to any libraries or applications, I am moving the bug here.

1. Demo of the issue:
        tar xvfz CGO_FALURE.tar.gz
        cd CGO_FALURE
        export GOPATH=`pwd`
        go run -compiler gccgo src/cgo_problem/demo.go
results in:
        # command-line-arguments
       
/tmp/go-build280712483/cgo_problem/example.com/libdemo.a(_cgo_export.o): In
function `Dummy':
       
/tmp/go-build280712483/cgo_problem/example.com/demo/_obj/_cgo_export.c:5:
undefined reference to `cgo_problem_example_com_demo.Cgoexp_Dummy'
        collect2: error: ld returned 1 exit status

2. Compare with the behavior of gc:
        go run -compiler gccgo src/cgo_problem/demo.go
results in:
        Address of function Dummy: 0x400f30

The issue can be worked around by renaming the example.com/demo package to
example_com/demo
        mv src/cgo_problem/example.com src/cgo_problem/example.com
        sed -i 's/example[.]com/example_com/' src/cgo_problem/demo.go

3. The problem stems from:

The _cgo_export.h file that is emitted by cgo.
The first part of the name given to __asm__ macro is generated by the
gccgoSymbolPrefix method here: http://golang.org/src/cmd/cgo/out.go#L985

Perhaps the runes that get emitted directly should include the dot '.' - it is
the domain delimiter character which is reused in package names.

4. gcc versions 4.8, 4.9, 4.10 suffer from this issue:

4.8:
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC) 


4.9:
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/ashopov/WORK/GCC/libexec/gcc/x86_64-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../configure --prefix=/home/ashopov/WORK/GCC
--build=x86_64-linux-gnu --disable-browser-plugin --disable-libgcj
--disable-libmudflap --disable-vtable-verify --disable-libunwind-exceptions
--enable-checking=release --disable-bootstrap --enable-__cxa_atexit
--enable-gnu-unique-object --enable-languages=c,c++,go,lto
--enable-linker-build-id --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --with-linker-hash-style=gnu --with-system-zlib
--with-tune=generic --enable-multiarch
Thread model: posix
gcc version 4.9.1 20140709 (prerelease) (GCC) 


4.10:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/ashopov/WORK/GCC-TRUNK/libexec/gcc/x86_64-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ./configure --prefix=/home/ashopov/WORK/GCC-TRUNK
--build=x86_64-linux-gnu --disable-browser-plugin --disable-libgcj
--disable-libmudflap --disable-vtable-verify --disable-libunwind-exceptions
--enable-checking=release --disable-bootstrap --enable-__cxa_atexit
--enable-gnu-unique-object --enable-languages=c,c++,go,lto
--enable-linker-build-id --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --with-linker-hash-style=gnu --with-system-zlib
--with-tune=generic --enable-multiarch
Thread model: posix
gcc version 4.10.0 20140721 (experimental) (GCC) 

5. System is:
Linux ashopov-dev 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux - up to date Fedora x86_64 box

6. gc/go are:
golang-1.2.2-7.fc20.x86_64

7. Sadly I could not convert this to a test case since 'go test' does not allow
using cgo.

[Bug go/61880] Linking with external functions in C does not work in GO when using gccgo, while it works in gc

[rth at gcc dot gnu.org]

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

Richard Henderson <rth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-09-25
                 CC|                            |rth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Richard Henderson <rth at gcc dot gnu.org> ---
Confirmed.  Given the pointer to cgo/out.go above, the patch for this at

https://launchpadlibrarian.net/183252940/0001-compiler-symbol-names-should-have-.-replaced-with-_.patch

looks correct to me.

[Bug go/61880] Linking with external functions in C does not work in GO when using gccgo, while it works in gc

[ian at gcc dot gnu.org]

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

--- Comment #2 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> ---
Author: ian
Date: Thu Oct  2 17:56:50 2014
New Revision: 215810

URL: https://gcc.gnu.org/viewcvs?rev=215810&root=gcc&view=rev
Log:
    PR go/61880
compiler: symbol names should have '.' replaced with '_'

Package and symbol names issued by the cgo tool and compiler
should be the same for the object files to link.

A minimal change to fix only:
   https://code.google.com/p/gofrontend/issues/detail?id=36
and
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880

Modified:
    trunk/gcc/go/gofrontend/gogo.cc

[Bug go/61880] Linking with external functions in C does not work in GO when using gccgo, while it works in gc

[ian at gcc dot gnu.org]

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

--- Comment #3 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> ---
Author: ian
Date: Thu Oct  2 18:00:01 2014
New Revision: 215812

URL: https://gcc.gnu.org/viewcvs?rev=215812&root=gcc&view=rev
Log:
    PR go/61880
compiler: symbol names should have '.' replaced with '_'

Package and symbol names issued by the cgo tool and compiler
should be the same for the object files to link.

A minimal change to fix only:
   https://code.google.com/p/gofrontend/issues/detail?id=36
and
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880

Modified:
    branches/gcc-4_9-branch/gcc/go/gofrontend/gogo.cc

[Bug go/61880] Linking with external functions in C does not work in GO when using gccgo, while it works in gc

[ian at airs dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |4.9.2

--- Comment #4 from Ian Lance Taylor <ian at airs dot com> ---
Fixed on mainline and 4.9 branch.

[Bug go/61880] Linking with external functions in C does not work in GO when using gccgo, while it works in gc

[jan.kratochvil at redhat dot com]

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

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan.kratochvil at redhat dot com

--- Comment #5 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
It causes GDB go testsuite regression:
https://sourceware.org/bugzilla/show_bug.cgi?id=17517

[Bug go/61880] Linking with external functions in C does not work in GO when using gccgo, while it works in gc

[ian at gcc dot gnu.org]

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

--- Comment #6 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> ---
Author: ian
Date: Fri Jan 30 00:35:44 2015
New Revision: 220268

URL: https://gcc.gnu.org/viewcvs?rev=220268&root=gcc&view=rev
Log:
compiler: Fix -fgo-prefix handling.

There was bug in the fix for PR 61880: it only worked fully
correctly for code compiled with -fgo-pkgpath.  For code that
used -fgo-prefix, or that used neither option, the '.'
separating the prefix and the package name was converted to an
underscore, which did not happen before.  This broke SWIG and
any other code that expected specific symbol names.
Fortunately all code compiled in libgo and all code compiled
by the go tool uses -fgo-pkgpath, so this probably did not
affect very many people.

This is an incomplete fix that does not modify the package
file format, for use on both mainline and the GCC 4.9 branch.
A follow on patch will fully fix the problem.

Modified:
    trunk/gcc/go/gofrontend/export.cc
    trunk/gcc/go/gofrontend/export.h
    trunk/gcc/go/gofrontend/gogo.cc
    trunk/gcc/go/gofrontend/gogo.h
    trunk/gcc/go/gofrontend/import.cc
    trunk/gcc/go/gofrontend/unsafe.cc

[Bug go/61880] Linking with external functions in C does not work in GO when using gccgo, while it works in gc

[ian at gcc dot gnu.org]

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

--- Comment #7 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> ---
Author: ian
Date: Fri Jan 30 00:36:14 2015
New Revision: 220269

URL: https://gcc.gnu.org/viewcvs?rev=220269&root=gcc&view=rev
Log:
compiler: Fix -fgo-prefix handling.

There was bug in the fix for PR 61880: it only worked fully
correctly for code compiled with -fgo-pkgpath.  For code that
used -fgo-prefix, or that used neither option, the '.'
separating the prefix and the package name was converted to an
underscore, which did not happen before.  This broke SWIG and
any other code that expected specific symbol names.
Fortunately all code compiled in libgo and all code compiled
by the go tool uses -fgo-pkgpath, so this probably did not
affect very many people.

This is an incomplete fix that does not modify the package
file format, for use on both mainline and the GCC 4.9 branch.
A follow on patch will fully fix the problem.

Modified:
    branches/gcc-4_9-branch/gcc/go/gofrontend/export.cc
    branches/gcc-4_9-branch/gcc/go/gofrontend/export.h
    branches/gcc-4_9-branch/gcc/go/gofrontend/gogo.cc
    branches/gcc-4_9-branch/gcc/go/gofrontend/gogo.h
    branches/gcc-4_9-branch/gcc/go/gofrontend/import.cc
    branches/gcc-4_9-branch/gcc/go/gofrontend/unsafe.cc