• 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
issue4029.c 242 Bytes