2010-10-25 18:55:50 -06: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.
|
|
|
|
|
|
|
|
|
|
// Export guts for testing.
|
|
|
|
|
|
|
|
|
|
package runtime
|
|
|
|
|
|
|
|
|
|
var Fadd64 = fadd64
|
|
|
|
|
var Fsub64 = fsub64
|
|
|
|
|
var Fmul64 = fmul64
|
|
|
|
|
var Fdiv64 = fdiv64
|
|
|
|
|
var F64to32 = f64to32
|
|
|
|
|
var F32to64 = f32to64
|
|
|
|
|
var Fcmp64 = fcmp64
|
|
|
|
|
var Fintto64 = fintto64
|
|
|
|
|
var F64toint = f64toint
|
2011-07-19 09:01:17 -06:00
|
|
|
|
|
|
|
|
func entersyscall()
|
|
|
|
|
func exitsyscall()
|
2011-11-07 22:53:31 -07:00
|
|
|
func golockedOSThread() bool
|
2012-03-15 13:22:30 -06:00
|
|
|
func stackguard() (sp, limit uintptr)
|
2011-07-19 09:01:17 -06:00
|
|
|
|
|
|
|
|
var Entersyscall = entersyscall
|
|
|
|
|
var Exitsyscall = exitsyscall
|
2011-11-07 22:53:31 -07:00
|
|
|
var LockedOSThread = golockedOSThread
|
2012-03-15 13:22:30 -06:00
|
|
|
var Stackguard = stackguard
|
2012-04-12 01:49:25 -06:00
|
|
|
|
|
|
|
|
type LFNode struct {
|
|
|
|
|
Next *LFNode
|
|
|
|
|
Pushcnt uintptr
|
|
|
|
|
}
|
|
|
|
|
|
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 lfstackpush_go(head *uint64, node *LFNode)
|
|
|
|
|
func lfstackpop_go(head *uint64) *LFNode
|
2012-04-12 01:49:25 -06:00
|
|
|
|
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
|
|
|
var LFStackPush = lfstackpush_go
|
|
|
|
|
var LFStackPop = lfstackpop_go
|
2012-05-11 00:50:03 -06:00
|
|
|
|
|
|
|
|
type ParFor struct {
|
|
|
|
|
body *byte
|
|
|
|
|
done uint32
|
|
|
|
|
Nthr uint32
|
|
|
|
|
nthrmax uint32
|
|
|
|
|
thrseq uint32
|
|
|
|
|
Cnt uint32
|
|
|
|
|
Ctx *byte
|
|
|
|
|
wait bool
|
|
|
|
|
}
|
|
|
|
|
|
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 newParFor(nthrmax uint32) *ParFor
|
|
|
|
|
func parForSetup(desc *ParFor, nthr, n uint32, ctx *byte, wait bool, body func(*ParFor, uint32))
|
|
|
|
|
func parForDo(desc *ParFor)
|
|
|
|
|
func parForIters(desc *ParFor, tid uintptr) (uintptr, uintptr)
|
2012-05-11 00:50:03 -06:00
|
|
|
|
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
|
|
|
var NewParFor = newParFor
|
|
|
|
|
var ParForSetup = parForSetup
|
|
|
|
|
var ParForDo = parForDo
|
2012-05-11 00:50:03 -06:00
|
|
|
|
|
|
|
|
func ParForIters(desc *ParFor, tid uint32) (uint32, uint32) {
|
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
|
|
|
begin, end := parForIters(desc, uintptr(tid))
|
2012-05-11 00:50:03 -06:00
|
|
|
return uint32(begin), uint32(end)
|
|
|
|
|
}
|
2013-02-22 21:48:02 -07:00
|
|
|
|
|
|
|
|
func testSchedLocalQueue()
|
|
|
|
|
func testSchedLocalQueueSteal()
|
|
|
|
|
|
|
|
|
|
var TestSchedLocalQueue1 = testSchedLocalQueue
|
|
|
|
|
var TestSchedLocalQueueSteal1 = testSchedLocalQueueSteal
|
2013-09-06 17:23:46 -06:00
|
|
|
|
|
|
|
|
func haveGoodHash() bool
|
|
|
|
|
func stringHash(s string, seed uintptr) uintptr
|
|
|
|
|
func bytesHash(b []byte, seed uintptr) uintptr
|
|
|
|
|
func int32Hash(i uint32, seed uintptr) uintptr
|
|
|
|
|
func int64Hash(i uint64, seed uintptr) uintptr
|
|
|
|
|
|
|
|
|
|
var HaveGoodHash = haveGoodHash
|
|
|
|
|
var StringHash = stringHash
|
|
|
|
|
var BytesHash = bytesHash
|
|
|
|
|
var Int32Hash = int32Hash
|
|
|
|
|
var Int64Hash = int64Hash
|
2013-09-13 12:19:23 -06:00
|
|
|
|
2013-10-04 14:54:03 -06:00
|
|
|
var hashLoad float64 // declared in hashmap.c
|
|
|
|
|
var HashLoad = &hashLoad
|
2014-02-06 18:43:22 -07:00
|
|
|
|
|
|
|
|
func memclrBytes(b []byte)
|
|
|
|
|
|
|
|
|
|
var MemclrBytes = memclrBytes
|
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 gogoBytes() int32
|
|
|
|
|
|
|
|
|
|
var GogoBytes = gogoBytes
|
runtime: handle Go calls C calls Go panic correctly on windows/386
32-bit Windows uses "structured exception handling" (SEH) to
handle hardware faults: that there is a per-thread linked list
of fault handlers maintained in user space instead of
something like Unix's signal handlers. The structures in the
linked list are required to live on the OS stack, and the
usual discipline is that the function that pushes a record
(allocated from the current stack frame) onto the list pops
that record before returning. Not to pop the entry before
returning creates a dangling pointer error: the list head
points to a stack frame that no longer exists.
Go pushes an SEH record in the top frame of every OS thread,
and that record suffices for all Go execution on that thread,
at least until cgo gets involved.
If we call into C using cgo, that called C code may push its
own SEH records, but by the convention it must pop them before
returning back to the Go code. We assume it does, and that's
fine.
If the C code calls back into Go, we want the Go SEH handler
to become active again, not whatever C has set up. So
runtime.callbackasm1, which handles a call from C back into
Go, pushes a new SEH record before calling the Go code and
pops it when the Go code returns. That's also fine.
It can happen that when Go calls C calls Go like this, the
inner Go code panics. We allow a defer in the outer Go to
recover the panic, effectively wiping not only the inner Go
frames but also the C calls. This sequence was not popping the
SEH stack up to what it was before the cgo calls, so it was
creating the dangling pointer warned about above. When
eventually the m stack was used enough to overwrite the
dangling SEH records, the SEH chain was lost, and any future
panic would not end up in Go's handler.
The bug in TestCallbackPanic and friends was thus creating a
situation where TestSetPanicOnFault - which causes a hardware
fault - would not find the Go fault handler and instead crash
the binary.
Add checks to TestCallbackPanicLocked to diagnose the mistake
in that test instead of leaving a bad state for another test
case to stumble over.
Fix bug by restoring SEH chain during deferred "endcgo"
cleanup.
This bug is likely present in Go 1.2.1, but since it depends
on Go calling C calling Go, with the inner Go panicking and
the outer Go recovering the panic, it seems not important
enough to bother fixing before Go 1.3. Certainly no one has
complained.
Fixes #7470.
LGTM=alex.brainman
R=golang-codereviews, alex.brainman
CC=golang-codereviews, iant, khr
https://golang.org/cl/71440043
2014-03-05 09:10:40 -07:00
|
|
|
|
|
|
|
|
func getseh_go() uintptr
|
|
|
|
|
|
|
|
|
|
var GetSEH = getseh_go
|
