- 28 Aug, 2014 6 commits
-
-
Russ Cox authored
The NaCl "system calls" were assumed to have a compatible return convention with the C compiler, and we were using tail jumps to those functions. Don't do that anymore. Correct mistake introduced in newstackcall duringconversion from (SP) to (FP) notation. (Actually this fix, in asm_amd64p32.s, slipped into the C compiler change, but update the name to match what go vet wants.) Correct computation of caller stack pointer in morestack: on amd64p32, the saved PC is the size of a uintreg, not uintptr. This may not matter, since it's been like this for a while, but uintreg is the correct one. (And on non-NaCl they are the same.) This will allow the NaCl build to get much farther. It will probably still not work completely. There's a bug in 6l that needs fixing too. TBR=minux CC=golang-codereviews https://golang.org/cl/134990043
-
Dave Cheney authored
runtime._sfloat2 now returns the lr value on the stack, not R0. Credit to Russ Cox for the fix. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/133120045
-
Russ Cox authored
TBR=minux CC=golang-codereviews https://golang.org/cl/137810043
-
Russ Cox authored
uintptr or uint64 in the runtime C were turning into uint in the Go, bool was turning into uint8, and so on. Fix that. Also delete Go wrappers for C functions. The C functions can be called directly now (but still eventually need to be converted to Go). LGTM=bradfitz, minux, iant R=golang-codereviews, bradfitz, iant, minux CC=golang-codereviews, khr, r https://golang.org/cl/138740043
-
Matthew Dempsky authored
Broken by 8b5fc7c59d05. Update #8092 LGTM=iant, alex.brainman R=rsc, iant, alex.brainman CC=golang-codereviews https://golang.org/cl/138770043
-
Matthew Dempsky authored
Fixes #8092. LGTM=rsc R=iant, rsc CC=golang-codereviews https://golang.org/cl/126790043
-
- 27 Aug, 2014 9 commits
-
-
Russ Cox authored
sighandler now returns its value on the stack. TBR=0intro CC=golang-codereviews https://golang.org/cl/135900043
-
Russ Cox authored
nanotime1 is not a Go function and must not store its result at 0(FP). That overwrites some data owned by the caller. TBR=aram CC=golang-codereviews https://golang.org/cl/138730043
-
Russ Cox authored
Windows needs the return result in AX, but runtime.sighandler no longer stores it in AX. Load it back during the assembly trampoline. TBR=brainman CC=golang-codereviews https://golang.org/cl/133980043
-
Russ Cox authored
The Go calling convention uses more stack space than C. On 64-bit systems we've been right up against the limit (128 bytes, so only 16 words) and doing awful things to our source code to work around it. Instead of continuing to do awful things, raise the limit to 160 bytes. I am prepared to raise the limit to 192 bytes if necessary, but I think this will be enough. Should fix current link-time stack overflow errors on - nacl/arm - netbsd/amd64 - openbsd/amd64 - solaris/amd64 - windows/amd64 TBR=r CC=golang-codereviews, iant https://golang.org/cl/131450043
-
Brad Fitzpatrick authored
It appears to have been accidentally lost when converting Stack from C to Go in https://golang.org/cl/129510043 LGTM=rsc R=golang-codereviews CC=golang-codereviews, josharian, khr, remyoudompheng, rsc https://golang.org/cl/136870043
-
Russ Cox authored
To date, the C compilers and Go compilers differed only in how values were returned from functions. This made it difficult to call Go from C or C from Go if return values were involved. It also made assembly called from Go and assembly called from C different. This CL changes the C compiler to use the Go conventions, passing results on the stack, after the arguments. [Exception: this does not apply to C ... functions, because you can't know where on the stack the arguments end.] By doing this, the CL makes it possible to rewrite C functions into Go one at a time, without worrying about which languages call that function or which languages it calls. This CL also updates all the assembly files in package runtime to use the new conventions. Argument references of the form 40(SP) have been rewritten to the form name+10(FP) instead, and there are now Go func prototypes for every assembly function called from C or Go. This means that 'go vet runtime' checks effectively every assembly function, and go vet's output was used to automate the bulk of the conversion. Some functions, like seek and nsec on Plan 9, needed to be rewritten. Many assembly routines called from C were reading arguments incorrectly, using MOVL instead of MOVQ or vice versa, especially on the less used systems like openbsd. These were found by go vet and have been corrected too. If we're lucky, this may reduce flakiness on those systems. Tested on: darwin/386 darwin/amd64 linux/arm linux/386 linux/amd64 If this breaks another system, the bug is almost certainly in the sys_$GOOS_$GOARCH.s file, since the rest of the CL is tested by the combination of the above systems. LGTM=dvyukov, iant R=golang-codereviews, 0intro, dave, alex.brainman, dvyukov, iant CC=golang-codereviews, josharian, r https://golang.org/cl/135830043
-
Rick Hudson authored
Every change to g->atomicstatus is now done atomically so that we can ensure that all gs pass through a gc safepoint on demand. This allows the GC to move from one phase to the next safely. In some phases the stack will be scanned. This CL only deals with the infrastructure that allows g->atomicstatus to go from one state to another. Future CLs will deal with scanning and monitoring what phase the GC is in. The major change was to moving to using a Gscan bit to indicate that the status is in a scan state. The only bug fix was in oldstack where I wasn't moving to a Gcopystack state in order to block scanning until the new stack was in place. The proc.go file is waiting for an atomic load instruction. LGTM=rsc R=golang-codereviews, dvyukov, josharian, rsc CC=golang-codereviews, khr https://golang.org/cl/132960044
-
Russ Cox authored
TBR=rlh CC=golang-codereviews https://golang.org/cl/131410043
-
Dave Cheney authored
Update #8527 Fixes two warnings: src/cmd/gc/mparith3.c:255:10: runtime error: shift exponent 52 is too large for 32-bit type 'int' src/cmd/gc/mparith3.c:254:14: runtime error: shift exponent 52 is too large for 32-bit type 'int' LGTM=rsc R=r, dvyukov, rsc CC=golang-codereviews https://golang.org/cl/134940044
-
- 26 Aug, 2014 11 commits
-
-
Rob Pike authored
Also make genzabbrs.go more self-contained. Also run it (on Linux; does that matter?) to update the table. LGTM=rsc R=rsc, alex.brainman CC=golang-codereviews https://golang.org/cl/128350044
-
Rob Pike authored
LGTM=mpvl, rsc R=mpvl, rsc CC=golang-codereviews https://golang.org/cl/135820043
-
Brad Fitzpatrick authored
Generated by a+c. R=gobot CC=golang-codereviews https://golang.org/cl/133040043
-
Josh Bleecher Snyder authored
Makes vet happy. LGTM=bradfitz R=dvyukov, bradfitz CC=golang-codereviews https://golang.org/cl/131320043
-
Oling Cat authored
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/130560043
-
Rémy Oudompheng authored
LGTM=khr R=khr, josharian CC=golang-codereviews https://golang.org/cl/129510043
-
Dave Cheney authored
I noticed that 5g doesn't flush the float64 result back to the stack, hence the change in the function signature. I'm wondering if I should also change the signature for the other two functions. LGTM=rsc R=minux, josharian, rsc CC=golang-codereviews https://golang.org/cl/132990044
-
Sanjay Menakuru authored
LGTM=dvyukov R=golang-codereviews, dvyukov CC=golang-codereviews, khr https://golang.org/cl/132880043
-
Brad Fitzpatrick authored
I can't reproduce the race, but this should fix it. Fixes #8483 LGTM=dvyukov R=dvyukov CC=golang-codereviews https://golang.org/cl/126610043
-
Brad Fitzpatrick authored
There are both many callers and many implementations of these interfaces, so make the contract explicit. Callers generally assume this, and at least the standard library and other implementations obey this, but it's never stated explicitly, making it somewhat risky to assume. LGTM=gri, rsc R=golang-codereviews, gri CC=golang-codereviews, r, rsc https://golang.org/cl/132150043
-
ChaiShushan authored
LGTM=r R=golang-codereviews, r CC=golang-codereviews https://golang.org/cl/133900043
-
- 25 Aug, 2014 14 commits
-
-
Caleb Spare authored
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/129620043
-
Russ Cox authored
For Solaris. Sigh. LGTM=dave R=aram, iant, dave CC=golang-codereviews https://golang.org/cl/129540043
-
Robert Griesemer authored
Also: use 0x644 file permission if a new file is created (should not happen anymore, though). LGTM=r R=r CC=golang-codereviews https://golang.org/cl/126610044
-
Rob Pike authored
Simplify the invocation (and speed it up substantially) in preparation for move to go generate. LGTM=bradfitz, mpvl R=mpvl, bradfitz, josharian CC=golang-codereviews https://golang.org/cl/135790043
-
Caleb Spare authored
Fixes #8143. LGTM=r R=rsc, bradfitz, r CC=golang-codereviews https://golang.org/cl/135760043
-
Rob Pike authored
Post-submit glitches caught by reviewers. LGTM=nightlyone, bradfitz R=golang-codereviews, nightlyone, bradfitz CC=golang-codereviews https://golang.org/cl/126660043
-
Dmitriy Vyukov authored
Once and for all. Broken in cl/108640043. I've messed it before. To test scavenger-related changes one needs to alter the constants during final testing. And then it's very easy to submit with the altered constants. LGTM=rsc R=golang-codereviews CC=golang-codereviews, rsc https://golang.org/cl/136720044
-
Dmitriy Vyukov authored
Deleted in cl/123700044. I am not sure whether I need to restore it, or delete rest of the uses... LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/129580043
-
Brad Fitzpatrick authored
Fixes #8261 LGTM=r R=r CC=golang-codereviews https://golang.org/cl/126620043
-
Adam Langley authored
Fixes #8576. LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/136720043
-
Russ Cox authored
Before, a slice with cap=0 or a string with len=0 might have its base pointer pointing beyond the actual slice/string data into the next block. The collector had to ignore slices and strings with cap=0 in order to avoid misinterpreting the base pointer. Now, a slice with cap=0 or a string with len=0 still has a base pointer pointing into the actual slice/string data, no matter what. The collector can now always scan the pointer, which means strings and slices are no longer special. Fixes #8404. LGTM=khr, josharian R=josharian, khr, dvyukov CC=golang-codereviews https://golang.org/cl/112570044
-
Rob Pike authored
Fixes test failure in build, probably a good idea anyway. LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/131210043
-
Rob Pike authored
LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/128710043
-
Brad Fitzpatrick authored
It was respected by unmarshal, but not marshal, so they didn't round-trip. Fixes #8582 LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/132960043
-