code review 7440045: runtime/cgo: move common symbol overrides into 6c-compi...

runtime/cgo: move common symbol overrides into 6c-compiled code

There are some function pointers declared by 6c in
package runtime without initialization and then also
declared in package runtime/cgo with initialization,
so that if runtime/cgo is linked in, the function pointers
are non-nil, and otherwise they are nil. We depend on
this property for implementing non-essential cgo hooks
in package runtime.

The declarations in package runtime are 6c-compiled
and end up in .6 files. The declarations in package runtime/cgo
are gcc-compiled and end up in .o files. Since 6l links the .6
and .o files together, this all works.

However, when we switch to "external linking" mode,
6l will not see the .o files, and it would be up to the host linker
to resolve the two into a single initialized symbol.
Not all host linkers will do this (in particular OS X gcc will not).

To fix this, move the cgo declarations into 6c-compiled code,
so that they end up in .6 files, so that 6l gets them no matter what.

[rsc, 2013-02-28 21:50:25]

Hello golang-dev@googlegroups.com,

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

[rsc, 2013-02-28 21:54:06]

Just moving code from file to file. TBR=anyone

[rsc, 2013-02-28 21:54:31]

*** Submitted as https://code.google.com/p/go/source/detail?r=86983e7002df ***

runtime/cgo: move common symbol overrides into 6c-compiled code

There are some function pointers declared by 6c in
package runtime without initialization and then also
declared in package runtime/cgo with initialization,
so that if runtime/cgo is linked in, the function pointers
are non-nil, and otherwise they are nil. We depend on
this property for implementing non-essential cgo hooks
in package runtime.

The declarations in package runtime are 6c-compiled
and end up in .6 files. The declarations in package runtime/cgo
are gcc-compiled and end up in .o files. Since 6l links the .6
and .o files together, this all works.

However, when we switch to "external linking" mode,
6l will not see the .o files, and it would be up to the host linker
to resolve the two into a single initialized symbol.
Not all host linkers will do this (in particular OS X gcc will not).

To fix this, move the cgo declarations into 6c-compiled code,
so that they end up in .6 files, so that 6l gets them no matter what.

R=golang-dev
CC=golang-dev
https://codereview.appspot.com/7440045

[bradfitz, 2013-03-01 00:37:21]

LGTM

On Thu, Feb 28, 2013 at 1:54 PM, <rsc@golang.org> wrote:

> *** Submitted as
>
https://code.google.com/p/go/**source/detail?r=86983e7002df<https://code.goog...
>
>
> runtime/cgo: move common symbol overrides into 6c-compiled code
>
> There are some function pointers declared by 6c in
> package runtime without initialization and then also
> declared in package runtime/cgo with initialization,
> so that if runtime/cgo is linked in, the function pointers
> are non-nil, and otherwise they are nil. We depend on
> this property for implementing non-essential cgo hooks
> in package runtime.
>
> The declarations in package runtime are 6c-compiled
> and end up in .6 files. The declarations in package runtime/cgo
> are gcc-compiled and end up in .o files. Since 6l links the .6
> and .o files together, this all works.
>
> However, when we switch to "external linking" mode,
> 6l will not see the .o files, and it would be up to the host linker
> to resolve the two into a single initialized symbol.
> Not all host linkers will do this (in particular OS X gcc will not).
>
> To fix this, move the cgo declarations into 6c-compiled code,
> so that they end up in .6 files, so that 6l gets them no matter what.
>
> R=golang-dev
> CC=golang-dev
>
https://codereview.appspot.**com/7440045<https://codereview.appspot.com/7440045>
>
>
>
https://codereview.appspot.**com/7440045/<https://codereview.appspot.com/7440...
>
> --
>
> ---You received this message because you are subscribed to the Google
> Groups "golang-dev" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
golang-dev+unsubscribe@**googlegroups.com<golang-dev%2Bunsubscribe@googlegrou...
> .
> For more options, visit
https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/o...
> .
>
>
>