code review 5822049: cmd/go: new cgo build procedure

cmd/go: new cgo build procedure
   This CL adds a step to the build procedure for cgo programs. It uses 'ld -r'
to combine all gcc compiled object file and generate a relocatable object file
for our ld. Additionally, this linking step will combine some static linking
gcc library into the relocatable object file, so that we can use libgcc, 
libmingwex and libmingw32 without problem.

   Fixes issue 3261.
   Fixes issue 1741.
   Added a testcase for linking in libgcc.

TODO: 
1. still need to fix the INDIRECT_SYMBOL_LOCAL problem on Darwin/386.
2. still need to enable the libgcc test on Linux/ARM, because 5l can't deal
with thumb libgcc.

Tested on Darwin/amd64, Darwin/386, FreeBSD/amd64, FreeBSD/386, Linux/amd64,
Linux/386, Linux/ARM, Windows/amd64, Windows/386

[minux1, 2012-03-16 10:32:17]

Hello iant@golang.org, rsc@golang.org (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go/

[rsc, 2012-03-16 16:25:16]

LGTM but wait for iant

[iant, 2012-03-16 18:01:20]

LGTM once the prerequisites are settled.

Thanks.

[minux1, 2012-04-17 19:15:30]

To be safe, I retested all three CLs on all systems I can access:

On Darwin/386, I got (but not on Darwin/amd64):
# ../misc/cgo/test
# testmain
/var/tmp/go-build23/_/Users/minux/work/go/go.hg/misc/cgo/test/_test/_/Users/minux/work/go/go.hg/misc/:

malformed mach-o file: invalid scattered relocat
FAIL	_/Users/minux/work/go/go.hg/misc/cgo/test [build failed]

Also, some ld warning during make.bash:

# crypto/x509
ld: warning: unexpected dylib
(/System/Library/Frameworks//CoreFoundation.framework/CoreFoundation) on link
line
ld: warning: unexpected dylib
(/System/Library/Frameworks//Security.framework/Security) on link line

I will address these issues before go on.

[minux1, 2012-04-19 20:52:56]

On 2012/04/17 19:15:30, minux wrote:
> To be safe, I retested all three CLs on all systems I can access:
I've tested on FreeBSD, Linux, Darwin, Windows. Only Darwin/386 fails.
 
> On Darwin/386, I got (but not on Darwin/amd64):
> # ../misc/cgo/test
> # testmain
>
/var/tmp/go-build23/_/Users/minux/work/go/go.hg/misc/cgo/test/_test/_/Users/minux/work/go/go.hg/misc/:
> 
> malformed mach-o file: invalid scattered relocat
This has something to do with INDIRECT_SYMBOL_LOCAL, which is a different
problem. I would prefer changing the libgcc test so that it won't involve this
kind of indirect symbol, and fix this problem in a later CL. What do you think?
 
> Also, some ld warning during make.bash: 
> # crypto/x509
> ld: warning: unexpected dylib
> (/System/Library/Frameworks//CoreFoundation.framework/CoreFoundation) on link
> line
we need to filter '-framework X' on Darwin, this is done.

[iant, 2012-04-19 21:10:17]

I'm not a Darwin user.  How would you change the test to avoid the "scattered
relocation" problem?

[minux1, 2012-04-20 09:21:29]

PTAL. I changed src/cmd/go/build.go and misc/cgo/test/issue3261.go.

On 2012/04/19 21:10:17, iant wrote:
> I'm not a Darwin user.  How would you change the test to avoid the "scattered
> relocation" problem?
the INDIRECT_SYMBOL_LOCAL problem only happens when some functions in libgcc
involves some local scoped table.
I changed to use __clzsi, and I think it could fix the problem.
(Am I right that we need to call __clzsi directly or gcc might inline it on
architectures that support clz instructions? Do you have any suggestions
on which libgcc function to use to avoid any static table on all architectures?)

[iant, 2012-04-20 20:38:48]

LGTM

The libgcc interface is fixed for a given architecture, but the libgcc code is
not.  It is of course possible that any libgcc function may use a static table. 
But the problem seems to point to a bug in 8l/6l, and I don't know if we need to
worry about that for this CL.

__clzsi does actually a static table on some architectures, but on x86 it uses
the bsr or lzcnt instruction.

There are certainly other libgcc functions that are likely to avoid static
tables, e.g., __addvsi3.

[rsc, 2012-05-03 21:59:24]

LGTM

[rsc, 2012-05-03 22:01:15]

This wouldn't help for Windows necessarily, but one thing we have been
considering in an attempt to make fancy C objects and especially C++
objects work well would be to give 6l and 8l a mode where they write a
.o file instead of an executable, and then invoke gcc to link that .o
file with the various other ELF objects found during the link, instead
of trying to do the linking themselves.  I don't know how much work
that would entail.

Russ

[minux1, 2012-05-04 17:00:29]

On Fri, May 4, 2012 at 6:00 AM, Russ Cox <rsc@golang.org> wrote:

> This wouldn't help for Windows necessarily, but one thing we have been
> considering in an attempt to make fancy C objects and especially C++
> objects work well would be to give 6l and 8l a mode where they write a
> .o file instead of an executable, and then invoke gcc to link that .o
> file with the various other ELF objects found during the link, instead
> of trying to do the linking themselves.  I don't know how much work
> that would entail.

I think the major linker work lies in generating the required relocations.
Linked by gcc means we will be linked with normal gcc startup routines
(crt0.o
and the like), thus we need to change runtime so that our entry point is
main().

This ability is directly related to issue 256: generating .so from Go code.

[rsc, 2012-05-04 17:03:20]

On Fri, May 4, 2012 at 1:00 PM, minux <minux.ma@gmail.com> wrote:
> I think the major linker work lies in generating the required relocations.
> Linked by gcc means we will be linked with normal gcc startup routines
> (crt0.o
> and the like), thus we need to change runtime so that our entry point is
> main().
>
> This ability is directly related to issue 256: generating .so from Go code.

Yes and no.  We can generate a .o file instead of a .so file,
and that should be at least a little less work.

Russ

[minux1, 2012-05-04 17:24:05]

On Sat, May 5, 2012 at 1:02 AM, Russ Cox <rsc@golang.org> wrote:

> On Fri, May 4, 2012 at 1:00 PM, minux <minux.ma@gmail.com> wrote:
> > I think the major linker work lies in generating the required
> relocations.
> > Linked by gcc means we will be linked with normal gcc startup routines
> > (crt0.o
> > and the like), thus we need to change runtime so that our entry point is
> > main().
> >
> > This ability is directly related to issue 256: generating .so from Go
> code.
>
> Yes and no.  We can generate a .o file instead of a .so file,
> and that should be at least a little less work.

I will try tackling this.
We can continue discussion at
http://code.google.com/p/go/issues/detail?id=3591.

[rsc, 2012-05-04 17:25:45]

On Fri, May 4, 2012 at 1:23 PM, minux <minux.ma@gmail.com> wrote:
> I will try tackling this.

Thanks!

[minux1, 2012-05-18 22:06:36]

I have a order problem here.
Once I submit this CL and its prerequisite, Linux/ARM build will be broken.
Because the builder's OS uses thumb libgcc, and cgo doesn't support thumb
library yet.

I do figure out a workaround, but it must change some part of code that is
changed in this CL series. Should I submit these CL first, and then prepare
the workaround CL or get the workaround in first and modify again these
three CL?

[bradfitz, 2012-05-18 23:11:41]

Keeping build green seems preferred.

I don't want to become a project that accepts red builds as normal.
On May 18, 2012 3:06 PM, <minux.ma@gmail.com> wrote:

> I have a order problem here.
> Once I submit this CL and its prerequisite, Linux/ARM build will be
> broken.
> Because the builder's OS uses thumb libgcc, and cgo doesn't support
> thumb
> library yet.
>
> I do figure out a workaround, but it must change some part of code that
> is
> changed in this CL series. Should I submit these CL first, and then
> prepare
> the workaround CL or get the workaround in first and modify again these
> three CL?
>
>
http://codereview.appspot.com/**5822049/<http://codereview.appspot.com/5822049/>
>

[rsc, 2012-05-21 17:19:13]

On Fri, May 18, 2012 at 6:06 PM,  <minux.ma@gmail.com> wrote:
> Once I submit this CL and its prerequisite, Linux/ARM build will be
> broken.
> Because the builder's OS uses thumb libgcc, and cgo doesn't support
> thumb
> library yet.
>
> I do figure out a workaround, but it must change some part of code that
> is
> changed in this CL series. Should I submit these CL first, and then
> prepare
> the workaround CL or get the workaround in first and modify again these
> three CL?

If you have three CLs that will go in one after the other and (say) the middle
one breaks the build but the final one fixes it, that's fine with me.

Anything that keeps the build broken for any period of time is not fine.

Russ

[ry, 2012-06-06 07:28:33]

This patch makes the build of the go repository hang at "net/rpc/jsonrpc". Top
shows two 6l processes at 100% CPU. This is run against changeset
13431:9b455eb64690 and patch set 16. Linux/x64.

[ry, 2012-06-06 08:58:36]

Using gdb, it seems to be spinning at src/cmd/ld/data.c:1094

[ry, 2012-06-06 09:29:07]

Nevermind - I wasn't on tip. Sorry.

[minux1, 2012-08-16 19:43:04]

*** Submitted as http://code.google.com/p/go/source/detail?r=5334356f42b3 ***

cmd/go: new cgo build procedure
   This CL adds a step to the build procedure for cgo programs. It uses 'ld -r'
to combine all gcc compiled object file and generate a relocatable object file
for our ld. Additionally, this linking step will combine some static linking
gcc library into the relocatable object file, so that we can use libgcc, 
libmingwex and libmingw32 without problem.

   Fixes issue 3261.
   Fixes issue 1741.
   Added a testcase for linking in libgcc.

TODO: 
1. still need to fix the INDIRECT_SYMBOL_LOCAL problem on Darwin/386.
2. still need to enable the libgcc test on Linux/ARM, because 5l can't deal
with thumb libgcc.

Tested on Darwin/amd64, Darwin/386, FreeBSD/amd64, FreeBSD/386, Linux/amd64,
Linux/386, Linux/ARM, Windows/amd64, Windows/386

R=iant, rsc, bradfitz, coldredlemur
CC=golang-dev
http://codereview.appspot.com/5822049