mirror of
https://github.com/golang/go
synced 2024-10-04 20:21:22 -06:00
67c83db60d
Package runtime's C functions written to be called from Go started out written in C using carefully constructed argument lists and the FLUSH macro to write a result back to memory. For some functions, the appropriate parameter list ended up being architecture-dependent due to differences in alignment, so we added 'goc2c', which takes a .goc file containing Go func declarations but C bodies, rewrites the Go func declaration to equivalent C declarations for the target architecture, adds the needed FLUSH statements, and writes out an equivalent C file. That C file is compiled as part of package runtime. Native Client's x86-64 support introduces the most complex alignment rules yet, breaking many functions that could until now be portably written in C. Using goc2c for those avoids the breakage. Separately, Keith's work on emitting stack information from the C compiler would require the hand-written functions to add #pragmas specifying how many arguments are result parameters. Using goc2c for those avoids maintaining #pragmas. For both reasons, use goc2c for as many Go-called C functions as possible. This CL is a replay of the bulk of CL 15400047 and CL 15790043, both of which were reviewed as part of the NaCl port and are checked in to the NaCl branch. This CL is part of bringing the NaCl code into the main tree. No new code here, just reformatting and occasional movement into .h files. LGTM=r R=dave, alex.brainman, r CC=golang-codereviews https://golang.org/cl/65220044 |
||
---|---|---|
.. | ||
a.h | ||
arg.h | ||
arm.c | ||
buf.c | ||
build.c | ||
buildgc.c | ||
buildgo.c | ||
buildruntime.c | ||
goc2c.c | ||
main.c | ||
plan9.c | ||
README | ||
unix.c | ||
windows.c |
This program, dist, is the bootstrapping tool for the Go distribution. It takes care of building the C programs (like the Go compiler) and the initial bootstrap copy of the go tool. It also serves as a catch-all to replace odd jobs previously done with shell scripts. Dist is itself written in very simple C. All interaction with C libraries, even standard C libraries, is confined to a single system-specific file (plan9.c, unix.c, windows.c), to aid portability. Functionality needed by other files should be exposed via the portability layer. Functions in the portability layer begin with an x prefix when they would otherwise use the same name as or be confused for an existing function. For example, xprintf is the portable printf. By far the most common data types in dist are strings and arrays of strings. Instead of using char* and char**, though, dist uses two named data structures, Buf and Vec, which own all the data they point at. The Buf operations are functions beginning with b; the Vec operations are functions beginning with v. The basic form of any function declaring Bufs or Vecs on the stack should be void myfunc(void) { Buf b1, b2; Vec v1; binit(&b1); binit(&b2); vinit(&v1); ... main code ... bprintf(&b1, "hello, world"); vadd(&v1, bstr(&b1)); // v1 takes a copy of its argument bprintf(&b2, "another string"); vadd(&v1, bstr(&b2)); // v1 now has two strings bfree(&b1); bfree(&b2); vfree(&v1); } The binit/vinit calls prepare a buffer or vector for use, initializing the data structures, and the bfree/vfree calls free any memory they are still holding onto. Use of this idiom gives us lexically scoped allocations.