2010-01-13 18:50:02 -07:00
|
|
|
|
// Copyright 2010 The Go Authors. All rights reserved.
|
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
|
|
package runtime
|
|
|
|
|
#include "runtime.h"
|
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 13:58:47 -07:00
|
|
|
|
#include "arch_GOARCH.h"
|
|
|
|
|
#include "type.h"
|
2010-01-13 18:50:02 -07:00
|
|
|
|
|
2012-09-24 12:58:34 -06:00
|
|
|
|
func GOMAXPROCS(n int) (ret int) {
|
runtime: ,s/[a-zA-Z0-9_]+/runtime·&/g, almost
Prefix all external symbols in runtime by runtime·,
to avoid conflicts with possible symbols of the same
name in linked-in C libraries. The obvious conflicts
are printf, malloc, and free, but hide everything to
avoid future pain.
The symbols left alone are:
** known to cgo **
_cgo_free
_cgo_malloc
libcgo_thread_start
initcgo
ncgocall
** known to linker **
_rt0_$GOARCH
_rt0_$GOARCH_$GOOS
text
etext
data
end
pclntab
epclntab
symtab
esymtab
** known to C compiler **
_divv
_modv
_div64by32
etc (arch specific)
Tested on darwin/386, darwin/amd64, linux/386, linux/amd64.
Built (but not tested) for freebsd/386, freebsd/amd64, linux/arm, windows/386.
R=r, PeterGo
CC=golang-dev
https://golang.org/cl/2899041
2010-11-04 12:00:19 -06:00
|
|
|
|
ret = runtime·gomaxprocsfunc(n);
|
2010-05-06 12:50:47 -06:00
|
|
|
|
}
|
2012-01-09 19:45:59 -07:00
|
|
|
|
|
2012-09-24 12:58:34 -06:00
|
|
|
|
func NumCPU() (ret int) {
|
2012-01-09 19:45:59 -07:00
|
|
|
|
ret = runtime·ncpu;
|
|
|
|
|
}
|
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 13:58:47 -07:00
|
|
|
|
|
|
|
|
|
func NumCgoCall() (ret int64) {
|
|
|
|
|
M *mp;
|
|
|
|
|
|
|
|
|
|
ret = 0;
|
|
|
|
|
for(mp=runtime·atomicloadp(&runtime·allm); mp; mp=mp->alllink)
|
|
|
|
|
ret += mp->ncgocall;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func newParFor(nthrmax uint32) (desc *ParFor) {
|
|
|
|
|
desc = runtime·parforalloc(nthrmax);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func parForSetup(desc *ParFor, nthr uint32, n uint32, ctx *byte, wait bool, body *byte) {
|
|
|
|
|
runtime·parforsetup(desc, nthr, n, ctx, wait, *(void(**)(ParFor*, uint32))body);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func parForDo(desc *ParFor) {
|
|
|
|
|
runtime·parfordo(desc);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func parForIters(desc *ParFor, tid uintptr) (start uintptr, end uintptr) {
|
|
|
|
|
runtime·parforiters(desc, tid, &start, &end);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func gogoBytes() (x int32) {
|
|
|
|
|
x = RuntimeGogoBytes;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func typestring(e Eface) (s String) {
|
|
|
|
|
s = *e.type->string;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func golockedOSThread() (ret bool) {
|
|
|
|
|
ret = runtime·lockedOSThread();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func NumGoroutine() (ret int) {
|
|
|
|
|
ret = runtime·gcount();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func getgoroot() (out String) {
|
|
|
|
|
byte *p;
|
|
|
|
|
|
|
|
|
|
p = runtime·getenv("GOROOT");
|
|
|
|
|
out = runtime·gostringnocopy(p);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We assume that all architectures turn faults and the like
|
|
|
|
|
* into apparent calls to runtime.sigpanic. If we see a "call"
|
|
|
|
|
* to runtime.sigpanic, we do not back up the PC to find the
|
|
|
|
|
* line number of the CALL instruction, because there is no CALL.
|
|
|
|
|
*/
|
|
|
|
|
void runtime·sigpanic(void);
|
|
|
|
|
|
|
|
|
|
func Caller(skip int) (retpc uintptr, retfile String, retline int, retbool bool) {
|
|
|
|
|
Func *f, *g;
|
|
|
|
|
uintptr pc;
|
|
|
|
|
uintptr rpc[2];
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Ask for two PCs: the one we were asked for
|
|
|
|
|
* and what it called, so that we can see if it
|
|
|
|
|
* "called" sigpanic.
|
|
|
|
|
*/
|
|
|
|
|
retpc = 0;
|
|
|
|
|
if(runtime·callers(1+skip-1, rpc, 2) < 2) {
|
|
|
|
|
retfile = runtime·emptystring;
|
|
|
|
|
retline = 0;
|
|
|
|
|
retbool = false;
|
|
|
|
|
} else if((f = runtime·findfunc(rpc[1])) == nil) {
|
|
|
|
|
retfile = runtime·emptystring;
|
|
|
|
|
retline = 0;
|
|
|
|
|
retbool = true; // have retpc at least
|
|
|
|
|
} else {
|
|
|
|
|
retpc = rpc[1];
|
|
|
|
|
pc = retpc;
|
|
|
|
|
g = runtime·findfunc(rpc[0]);
|
|
|
|
|
if(pc > f->entry && (g == nil || g->entry != (uintptr)runtime·sigpanic))
|
|
|
|
|
pc--;
|
|
|
|
|
retline = runtime·funcline(f, pc, &retfile);
|
|
|
|
|
retbool = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func Callers(skip int, pc Slice) (retn int) {
|
|
|
|
|
// runtime.callers uses pc.array==nil as a signal
|
|
|
|
|
// to print a stack trace. Pick off 0-length pc here
|
|
|
|
|
// so that we don't let a nil pc slice get to it.
|
|
|
|
|
if(pc.len == 0)
|
|
|
|
|
retn = 0;
|
|
|
|
|
else
|
|
|
|
|
retn = runtime·callers(skip, (uintptr*)pc.array, pc.len);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func runtime∕pprof·runtime_cyclesPerSecond() (res int64) {
|
|
|
|
|
res = runtime·tickspersecond();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func sync·runtime_procPin() (p int) {
|
|
|
|
|
M *mp;
|
|
|
|
|
|
all: remove 'extern register M *m' from runtime
The runtime has historically held two dedicated values g (current goroutine)
and m (current thread) in 'extern register' slots (TLS on x86, real registers
backed by TLS on ARM).
This CL removes the extern register m; code now uses g->m.
On ARM, this frees up the register that formerly held m (R9).
This is important for NaCl, because NaCl ARM code cannot use R9 at all.
The Go 1 macrobenchmarks (those with per-op times >= 10 µs) are unaffected:
BenchmarkBinaryTree17 5491374955 5471024381 -0.37%
BenchmarkFannkuch11 4357101311 4275174828 -1.88%
BenchmarkGobDecode 11029957 11364184 +3.03%
BenchmarkGobEncode 6852205 6784822 -0.98%
BenchmarkGzip 650795967 650152275 -0.10%
BenchmarkGunzip 140962363 141041670 +0.06%
BenchmarkHTTPClientServer 71581 73081 +2.10%
BenchmarkJSONEncode 31928079 31913356 -0.05%
BenchmarkJSONDecode 117470065 113689916 -3.22%
BenchmarkMandelbrot200 6008923 5998712 -0.17%
BenchmarkGoParse 6310917 6327487 +0.26%
BenchmarkRegexpMatchMedium_1K 114568 114763 +0.17%
BenchmarkRegexpMatchHard_1K 168977 169244 +0.16%
BenchmarkRevcomp 935294971 914060918 -2.27%
BenchmarkTemplate 145917123 148186096 +1.55%
Minux previous reported larger variations, but these were caused by
run-to-run noise, not repeatable slowdowns.
Actual code changes by Minux.
I only did the docs and the benchmarking.
LGTM=dvyukov, iant, minux
R=minux, josharian, iant, dave, bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/109050043
2014-06-26 09:54:39 -06:00
|
|
|
|
mp = g->m;
|
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 13:58:47 -07:00
|
|
|
|
// Disable preemption.
|
|
|
|
|
mp->locks++;
|
|
|
|
|
p = mp->p->id;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func sync·runtime_procUnpin() {
|
all: remove 'extern register M *m' from runtime
The runtime has historically held two dedicated values g (current goroutine)
and m (current thread) in 'extern register' slots (TLS on x86, real registers
backed by TLS on ARM).
This CL removes the extern register m; code now uses g->m.
On ARM, this frees up the register that formerly held m (R9).
This is important for NaCl, because NaCl ARM code cannot use R9 at all.
The Go 1 macrobenchmarks (those with per-op times >= 10 µs) are unaffected:
BenchmarkBinaryTree17 5491374955 5471024381 -0.37%
BenchmarkFannkuch11 4357101311 4275174828 -1.88%
BenchmarkGobDecode 11029957 11364184 +3.03%
BenchmarkGobEncode 6852205 6784822 -0.98%
BenchmarkGzip 650795967 650152275 -0.10%
BenchmarkGunzip 140962363 141041670 +0.06%
BenchmarkHTTPClientServer 71581 73081 +2.10%
BenchmarkJSONEncode 31928079 31913356 -0.05%
BenchmarkJSONDecode 117470065 113689916 -3.22%
BenchmarkMandelbrot200 6008923 5998712 -0.17%
BenchmarkGoParse 6310917 6327487 +0.26%
BenchmarkRegexpMatchMedium_1K 114568 114763 +0.17%
BenchmarkRegexpMatchHard_1K 168977 169244 +0.16%
BenchmarkRevcomp 935294971 914060918 -2.27%
BenchmarkTemplate 145917123 148186096 +1.55%
Minux previous reported larger variations, but these were caused by
run-to-run noise, not repeatable slowdowns.
Actual code changes by Minux.
I only did the docs and the benchmarking.
LGTM=dvyukov, iant, minux
R=minux, josharian, iant, dave, bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/109050043
2014-06-26 09:54:39 -06:00
|
|
|
|
g->m->locks--;
|
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 13:58:47 -07:00
|
|
|
|
}
|