Skip to content

G
golang
Switch branch/tag
  1. 20 Nov, 2015 6 commits
    • Hyang-Ah Hana Kim's avatar
      cmd/dist: run testcshared test on linux/386 · ec3daf0c
      Hyang-Ah Hana Kim authored 
      Change-Id: Iaa0fb133e5fc2078bfaf59ed721fd07a1a713ab3
Reviewed-on: https://go-review.googlesource.com/17075Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      ec3daf0c
    • Hyang-Ah Hana Kim's avatar
      cmd/go, cmd/link: enable -buildmode=c-shared on linux/386 · cbc55971
      Hyang-Ah Hana Kim authored 
      All the heavy lifting was done by Michael Hudson-Doyle.

Change-Id: I176f15581055078854c2ad9a5807c4dcf0f8d8c5
Reviewed-on: https://go-review.googlesource.com/17074Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      cbc55971
    • Russ Cox's avatar
      runtime: make asmcgocall work without a g · 3af29fb8
      Russ Cox authored 
      Solaris needs to make system calls without a g,
and Solaris uses asmcgocall to make system calls.
I know, I know.

I hope this makes CL 16915, fixing #12277, work on Solaris.

Change-Id: If988dfd37f418b302da9c7096f598e5113ecea87
Reviewed-on: https://go-review.googlesource.com/17072Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
Reviewed-by: 's avatarAram Hăvărneanu <aram@mgk.ro>
Run-TryBot: Russ Cox <rsc@golang.org>
      3af29fb8
    • Rob Pike's avatar
      cmd/go: make it clearer that go generate accepts all build flags · 997ed6fd
      Rob Pike authored 
      Just add one word to clarify that -n -v -x are not the only build flags supported.

Fixes #13237.

Change-Id: I880472639bf2fc1a0751a83041bc7ddd0c9e55f4
Reviewed-on: https://go-review.googlesource.com/17062Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      997ed6fd
    • Ian Lance Taylor's avatar
      cmd/cgo: final docs for pointer passing · f2a0fc10
      Ian Lance Taylor authored 
      Update #12416.

Change-Id: I39eb0d1090c08ef9be9dc38d27abab62672cf664
Reviewed-on: https://go-review.googlesource.com/17064Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      f2a0fc10
    • Ian Lance Taylor's avatar
      cmd/cgo: put the real C function in the dynamic symbol table · 5005a339
      Ian Lance Taylor authored 
      In the past, cgo generated Go code and C code.  The C code was linked
into a shared library.  The Go code was built into an executable that
dynamically linked against that shared library.  C wrappers were
exported from the shared library, and the Go code called them.

It was all a long time ago, but in order to permit C code to call back
into Go, somebody implemented #pragma dynexport (https://golang.org/cl/661043)
to export a Go symbol into the dynamic symbol table.  Then that same
person added code to cgo to recognize //export comments
(https://golang.org/cl/853042).  The //export comments were implemented
by generating C code, to be compiled by GCC, that would refer to C code,
to be compiled by 6c, that would call the Go code.  The GCC code would
go into a shared library.  The code compiled by 6c would be in the Go
executable.  The GCC code needed to refer to the 6c code, so the 6c
function was marked with #pragma dynexport.  The important point here is
that #pragma dynexport was used to expose an internal detail of the
implementation of an exported function, because at the time it was
necessary.

Moving forward to today, cgo no longer generates a shared library and 6c
no longer exists.  It's still true that we have a function compiled by
GCC that refers to a wrapper function now written in Go.  In the normal
case today we are doing an external link, and we use a
//go:cgo_export_static function to make the Go wrapper function visible
to the C code under a known name.

The #pragma dynexport statement has become a //go:cgo_export_dynamic
comment on the Go code.  That comment only takes effect when doing
internal linking.  The comment tells the linker to put the symbol in the
dynamic symbol table.  That still makes sense for the now unusual case
of using internal linking with a shared library.

However, all the changes to this code have carefully preserved the
property that the //go:cgo_export_dynamic comment refers to an internal
detail of the implementation of an exported function.  That was
necessary a long time ago, but no longer makes sense.

This CL changes the code to put the actual C-callable function into the
dynamic symbol table.  I considered dropping the comment entirely, but
it turns out that there is even a test for this, so I preserved it.

Change-Id: I66a7958e366e5974363099bfaa6ba862ca327849
Reviewed-on: https://go-review.googlesource.com/17061
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: 's avatarMinux Ma <minux@golang.org>
      5005a339
  3. 19 Nov, 2015 22 commits
  5. 18 Nov, 2015 12 commits