1
0
mirror of https://github.com/golang/go synced 2024-10-04 20:21:22 -06:00
go/src/cmd/dist
Russ Cox 67c83db60d runtime: use goc2c as much as possible
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
2014-02-20 15:58:47 -05:00
..
a.h cmd/go, cmd/cgo, make.bash: cross compiling with cgo enabled 2014-02-06 09:11:00 -08:00
arg.h build: dist-based build for Plan 9 2012-05-01 22:32:46 -07:00
arm.c cmd/dist: support for NetBSD/ARM 2013-03-03 06:50:17 +08:00
buf.c cmd/dist: clear execute bit from source file 2012-02-11 13:23:44 +09:00
build.c cmd/addr2line: reimplement in Go 2014-02-19 14:33:11 -05:00
buildgc.c cmd/dist: add liblink build information 2013-12-08 22:48:11 -05:00
buildgo.c cmd/go, cmd/cgo, make.bash: cross compiling with cgo enabled 2014-02-06 09:11:00 -08:00
buildruntime.c runtime: use goc2c as much as possible 2014-02-20 15:58:47 -05:00
goc2c.c runtime: use goc2c as much as possible 2014-02-20 15:58:47 -05:00
main.c cmd/dist, build: support building statically linked toolchain 2013-10-01 23:44:20 -04:00
plan9.c all: be more idiomatic when documenting boolean return values. 2013-07-23 11:59:49 +10:00
README cmd/dist: fix code example in README 2013-01-30 08:46:50 -08:00
unix.c lib9, libmach, cmd/dist, go/build: add support for GOOS=solaris 2014-01-07 23:12:12 +11:00
windows.c cmd/dist: fix crash on windows 2013-07-27 13:53:18 +04:00

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.