The current failure is:
fatal error: runtime: stack split during syscall
goroutine 2 [stack split]:
_si2v(0xb6ebaebc, 0x3b9aca00)
/usr/local/go/src/pkg/runtime/vlrt_arm.c:628 fp=0xb6ebae9c
runtime.timediv(0xf8475800, 0xd, 0x3b9aca00, 0xb6ebaef4)
/usr/local/go/src/pkg/runtime/runtime.c:424 +0x1c fp=0xb6ebaed4
Just adding textflag 7 causes the following error:
notetsleep: nosplit stack overflow
128 assumed on entry to notetsleep
96 after notetsleep uses 32
60 after runtime.futexsleep uses 36
4 after runtime.timediv uses 56
-4 after _si2v uses 8
runtime: fix openbsd build
notetsleep: nosplit stack overflow
120 assumed on entry to notetsleep
96 after notetsleep uses 24
88 on entry to runtime.semasleep
32 after runtime.semasleep uses 56
24 on entry to runtime.nanotime
-8 after runtime.nanotime uses 32
Nanotime seems to be using only 24 bytes of stack space.
Unless I am missing something.
runtime: fix freebsd build
notetsleep: nosplit stack overflow
120 assumed on entry to notetsleep
80 after notetsleep uses 40
72 on entry to runtime.futexsleep
16 after runtime.futexsleep uses 56
8 on entry to runtime.printf
-16 after runtime.printf uses 24
runtime: do not split stacks in syscall status
Split stack checks (morestack) corrupt g->sched,
but g->sched must be preserved consistent for GC/traceback.
The change implements runtime.notetsleepg function,
which does entersyscall/exitsyscall and is carefully arranged
to not call any split functions in between.
David Symonds [Mon, 29 Jul 2013 02:08:19 +0000 (12:08 +1000)]
misc/dashboard: don't update tip tag for release branch commits.
This will mean that sub-repositories won't get built against the
release branch. They are often not compatible because the subrepos
often run ahead of the current release (e.g. go.tools is using
new additions to go/ast, and go.net is using new things in syscall)
so there's little point in checking them against cherrypick commits
when they'll be tested against those commits on tip anyway.
net: extend sockaddr interface to the all address families
This CL extends existing sockaddr interface to accommodate not only
internet protocol family endpoint addressess but unix network family
endpoint addresses.
This is in preparation for runtime-integrated network pollster for BSD
variants.
Update #5199
R=golang-dev, dave
CC=golang-dev
https://golang.org/cl/11979043
runtime: fix potential deadlock in netpoll on windows
If netpoll has been told to block, it must not return with nil,
otherwise scheduler assumes that netpoll is disabled.
misc/notepadplus: use new User Defined Language system (UDL2)
Add missing single quotation and backslash marks.
Change dot and underscore character keyword type.
"_" is a predeclared identifier, not a operator.
"." is a selector, x.f should be one identifier highlight.
So the fix is to change it.
Fixes #5775.
Fixes #5788.
Fixes #5798.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10480044
runtime: refactor mallocgc
Make it accept type, combine flags.
Several reasons for the change:
1. mallocgc and settype must be atomic wrt GC
2. settype is called from only one place now
3. it will help performance (eventually settype
functionality must be combined with markallocated)
4. flags are easier to read now (no mallocgc(sz, 0, 1, 0) anymore)
R=golang-dev, iant, nightlyone, rsc, dave, khr, bradfitz, r
CC=golang-dev
https://golang.org/cl/10136043
cmd/gc: avoid passing unevaluated constant expressions to backends.
Backends do not exactly expect receiving binary operators with
constant operands or use workarounds to move them to
register/stack in order to handle them.
This also adds another test which makes sure that the sums
over larger blocks work properly. I wrote this test when I was
worried about memory corruption.
Kevin Klues [Thu, 25 Jul 2013 00:27:42 +0000 (17:27 -0700)]
cmd/cgo: Fix issue with cgo cdefs
The problem is that the cdecl() function in cmd/cgo/godefs.go isn't
properly translating the Go array type to a C array type when an
asterisk follows the [] in the array type declaration (it is perfectly
legal to put the asterisk on either side of the [] in go syntax,
depending on how you set up your pointers).
That said, the cdefs tool is only designed to translate from Go types
generated using the cgo *godefs* tool -- where the godefs tool is
designed to translate gcc-style C types into Go types. In essence, the
cdefs tool translates from gcc-style C types to Go types (via the godefs
tool), then back to kenc-style C types. Because of this, cdefs does not
need to know how to translate arbitraty Go types into C, just the ones
produced by godefs.
The problem is that during this translation process, the logic is
slightly wrong when going from (e.g.):
char *array[10];
to:
array [10]*int8;
back to:
int8 *array[10];
In the current implementation of cdecl(), the translation from the Go
type declaration back to the kenc-style declaration looks for Go
types of the form:
name *[]type;
rather than the actual generated Go type declaration of:
name []*type;
Both are valid Go syntax, with slightly different semantics, but the
latter is the only one that can ever be generated by the godefs tools.
(The semantics of the former are not directly expressible in a
single C statement -- you would have to have to first typedef the array
type, then declare a pointer to that typedef'd type in a separate
statement).
This commit changes the logic of cdecl() to look properly for, and
translate, Go type declarations of the form:
name []*type;
Additionally, the original implementation only allowed for a single
asterisk and a single sized aray (i.e. only a single level of pointer
indirection, and only one set of []) on the type, whereas the patched
version allows for an arbitrary number of both.
Tests are included in misc/cgo/testcdefs and the all.bash script has been
updated to account for these.
Ian Lance Taylor [Wed, 24 Jul 2013 17:28:57 +0000 (10:28 -0700)]
log/syslog: restore use of serverConn interface
Revision 15629 (8d71734a0cb0) removed the serverConn interface
that was introduce in revision 7718 (ee5e80c62862). The
serverConn interface was there for use by gccgo on Solaris,
and it is still needed there. Solaris does not support
connecting to the syslog daemon over TCP, and gccgo simply
calls the C library function. This CL restores the
interface.
runtime: drop EV_RECEIPT support from network pollster on kqueue
Currently Darwin and FreeBSD support and NetBSD and OpenBSD do not
support EV_RECEIPT flag. We will drop use of EV_RECEIPT for now.
Also enables to build runtime-integrated network pollster on
freebsd/amd64,386 and openbsd/amd64,386. It just does build but never
runs pollster stuff.
This is in preparation for runtime-integrated network pollster for BSD
variants.
Debugging the Windows breakage I noticed that SEH
only exists on 386, so we can balance the two stacks
a little more on amd64 and reclaim another word.
Now we're down to just one word consumed by
cgocallback_gofunc, having reclaimed 25% of the
overall budget (4 words out of 16).
Separately, fix windows/386 - the SEH must be on the
m0 stack, as must the saved SP, so we are forced to have
a three-word frame for 386. It matters much less for
386, because there 128 bytes gives 32 words to use.
Rob Pike [Wed, 24 Jul 2013 00:27:58 +0000 (10:27 +1000)]
unicode: add "In" function to test membership of a rune
The existing function, IsOneOf, is hard to use. Since the slice comes
before the rune, in parallelism with the other Is functions, the slice
is clumsy to build. This CL adds a nicer-signatured In function of
equivalent functionality (its implementation is identical) that's much
easier to use. Compare:
unicode.IsOneOf([]*unicode.RangeTable{unicode.Letter, unicode.Number}, r)
unicode.In(r, unicode.Letter, unicode.Number)
runtime: reduce frame size for runtime.cgocallback_gofunc
Tying preemption to stack splits means that we have to able to
complete the call to exitsyscall (inside cgocallbackg at least for now)
without any stack split checks, meaning that the whole sequence
has to work within 128 bytes of stack, unless we increase the size
of the red zone. This CL frees up 24 bytes along that critical path
on amd64. (The 32-bit systems have plenty of space because all
their words are smaller.)
Rob Pike [Tue, 23 Jul 2013 01:59:49 +0000 (11:59 +1000)]
all: be more idiomatic when documenting boolean return values.
Phrases like "returns whether or not the image is opaque" could be
describing what the function does (it always returns, regardless of
the opacity) or what it returns (a boolean indicating the opacity).
Even when the "or not" is missing, the phrasing is bizarre.
Go with "reports whether", which is still clunky but at least makes
it clear we're talking about the return value.
These were edited by hand. A few were cleaned up in other ways.
David du Colombier [Mon, 22 Jul 2013 21:33:41 +0000 (17:33 -0400)]
cmd/ld: fix warnings on Plan 9
src/cmd/ld/lib.c:1379 set and not used: p
src/cmd/ld/lib.c:1426 format mismatch 6llux INT, arg 3
src/cmd/ld/lib.c:1437 format mismatch 6llux INT, arg 3
src/cmd/ld/lib.c:1456 format mismatch 6llux INT, arg 3
src/cmd/ld/lib.c:1477 format mismatch 6llux INT, arg 3
src/cmd/ld/lib.c:1459 set and not used: started
runtime: introduce notetsleepg function
notetsleepg is the same as notetsleep, but is called on user g.
It includes entersyscall/exitsyscall and will help to avoid
split stack functions in syscall status.
cmd/dist, cmd/go: enable more warnings, make clang errors legible
This does not change the default compiler on OS X to clang.
It appears that for now we can keep using gcc as long as we
enable a few more warning settings that are on-by-default
elsewhere.
R=golang-dev, bradfitz, dave
CC=golang-dev
https://golang.org/cl/11610044
runtime: use funcdata to supply garbage collection information
This CL introduces a FUNCDATA number for runtime-specific
garbage collection metadata, changes the C and Go compilers
to emit that metadata, and changes the runtime to expect it.
The old pseudo-instructions that carried this information
are gone, as is the linker code to process them.
Keith Randall [Fri, 19 Jul 2013 18:19:18 +0000 (11:19 -0700)]
runtime: cleanup: use ArgsSizeUnknown to mark all functions
whose argument size is unknown (C vararg functions, and
assembly code without an explicit specification).
We used to use 0 to mean "unknown" and 1 to mean "zero".
Now we use ArgsSizeUnknown (0x80000000) to mean "unknown".