code review 9738047: runtime: Add shared library support (linux/amd64)

runtime: Add shared library support (linux/amd64+linux/arm)

Add the nescessary hooks to enable Go programs to be output
to a shared library and called from foreign programs, e.g. C.

The linker registers _rt0_amd64|arm_linux_lib to be run as a library
initialization function. On the first cgo callback from the main
program, _cgo_lib_init is called. _cgo_lib_init in turn
starts a new thread that runs the Go runtime initialization,
_rt0_amd64/_rt0_arm_linux1.  _cgo_lib_init uses a barrier to wait for
the runtime to complete inititialization before continuing.

Other than running on a new thread, the Go runtime itself is not changed,
except for allowing (and expecting) the Go main() function to complete.

Since argc and argv cannot be reliably accessed from a shared library
initializer, the runtime is changed to allow os.Args to have zero length.
In that case, auxv is fetched from /proc/auxv instead.

The environment is fetched from the global variable environ.

Deadlock detection is effectively disabled in shared library mode, even when
no Cgo calls have been made, since it is not possible to determine whether
the main program will call into Go at some later time.

On amd64 the test must be run manually,
since -shared is only supported when the standard library have been built
with -largeflags:

GO_GCFLAGS=-largemodel GO_CCFLAGS=-largemodel ./all.bash

On ARM the test is run as part of the test suite in run.bash.

Updates issue 4848.
Updates issue 256.
Updates issue 2790.

Design proposal at https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/zmjXkGrEx6Q

[elias.naur, 2013-05-29 20:18:51]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://go.googlecode.com/hg/

[rsc, 2013-06-03 20:12:02]

I'd like to see the design fleshed out more before checking in or reviewing
code.
There are a lot of open questions here.

All the problems from last year remain: why should the init only happen once but
the main start anew on each call? Why is it reasonable for os.Args to be empty?
What about the environment? And so on.

I really want to know what kind of interface we are trying to build. 

Let's continue that discussion on the golang-nuts thread.

[elias.naur, 2013-06-24 15:22:28]

Added linux/arm support and updated to apply to tip.

[gobot, 2013-12-20 16:11:03]

Replacing golang-dev with golang-codereviews.

[oleku, 2014-04-04 10:56:44]

On 2013/06/24 15:22:28, elias.naur wrote:
> Added linux/arm support and updated to apply to tip.

Any update on this ?

[rsc, 2014-04-07 13:57:03]

This won't be in Go 1.3. We still need to work out and agree on the
semantics we are trying to implement.

[oleku, 2014-04-07 17:05:18]

Thanks for the update .. would remind you after the 1.3 release ...

On Monday, April 7, 2014 2:57:02 PM UTC+1, russ cox wrote:
> This won't be in Go 1.3. We still need to work out and agree on the semantics
we are trying to implement.

[rsc, 2014-04-17 02:53:50]

R=close

please 'hg mail' after 1.3 to reopen

https://codereview.appspot.com/9738047/diff/37001/src/pkg/runtime/os_linux_arm.c
File src/pkg/runtime/os_linux_arm.c (right):

https://codereview.appspot.com/9738047/diff/37001/src/pkg/runtime/os_linux_ar...
src/pkg/runtime/os_linux_arm.c:35: #pragma textflag 7
please hg sync to start using NOSPLIT

https://codereview.appspot.com/9738047/diff/37001/src/pkg/runtime/os_linux_ar...
src/pkg/runtime/os_linux_arm.c:37: parse_auxv_entry(uint32 key, uint32 val) {
{ on next line

[ishan.anand, 2014-07-17 20:38:30]

Now that 1.3 is out, any shot of this going in the next release? Working on an
open source Go library that would be great to distribute as a runtime that C
programs can link to.

On 2014/04/17 02:53:50, rsc wrote:
> R=close
> 
> please 'hg mail' after 1.3 to reopen
> 
>
https://codereview.appspot.com/9738047/diff/37001/src/pkg/runtime/os_linux_arm.c
> File src/pkg/runtime/os_linux_arm.c (right):
> 
>
https://codereview.appspot.com/9738047/diff/37001/src/pkg/runtime/os_linux_ar...
> src/pkg/runtime/os_linux_arm.c:35: #pragma textflag 7
> please hg sync to start using NOSPLIT
> 
>
https://codereview.appspot.com/9738047/diff/37001/src/pkg/runtime/os_linux_ar...
> src/pkg/runtime/os_linux_arm.c:37: parse_auxv_entry(uint32 key, uint32 val) {
> { on next line

[minux, 2014-07-18 19:22:51]

On Thu, Jul 17, 2014 at 4:38 PM, <ishan.anand@gmail.com> wrote:

> Now that 1.3 is out, any shot of this going in the next release? Working
> on an open source Go library that would be great to distribute as a
> runtime that C programs can link to.
>
I think we need to discuss the details first on golang-dev.
One such detail is: if I load two Go shared libraries, should them be able
to
communicate directly? e.g. can i pass a channel from one to another?

limited linux/arm dyanmic library support is already in the tree to support
android/arm.