It turns out that _cgo_malloc is used, via cmalloc in
runtime/cgocall.c, which is called by code generated by out.go
for the ·_C_CString function. I can't find a call to
_cgo_free, but given _cgo_malloc we might as well keep
_cgo_free. This patch fixes it so that it should work on
amd64.
R=rsc
CC=golang-dev
https://golang.org/cl/
1399041
#pragma dynimport libcgo_thread_start libcgo_thread_start "%s/libcgo.so"
#pragma dynimport libcgo_set_scheduler libcgo_set_scheduler "%s/libcgo.so"
#pragma dynimport _cgo_malloc _cgo_malloc "%s/libcgo.so"
-#pragma dynimport _cgo_free free "%s/libcgo.so"
+#pragma dynimport _cgo_free _cgo_free "%s/libcgo.so"
void
·_C_GoString(int8 *p, String s)
#include "libcgo.h"
-/* Stub for calling malloc from the other world */
+/* Stub for calling malloc from Go */
void
_cgo_malloc(void *p)
{
a->ret = malloc(a->n);
}
+/* Stub for calling from Go */
+void
+_cgo_free(void *p)
+{
+ struct a {
+ void *arg;
+ } *a = p;
+
+ free(a->arg);
+}
+
/* Stub for creating a new thread */
void
libcgo_thread_start(ThreadStart *arg)