1. 28 Aug, 2014 18 commits
  2. 27 Aug, 2014 9 commits
    • Russ Cox's avatar
      runtime: fix plan9 build · 9e360926
      Russ Cox authored
      sighandler now returns its value on the stack.
      
      TBR=0intro
      CC=golang-codereviews
      https://golang.org/cl/135900043
      9e360926
    • Russ Cox's avatar
      runtime: fix solaris build · 997809c8
      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
      997809c8
    • Russ Cox's avatar
      runtime: fix windows signal handlers · c548cc2e
      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
      c548cc2e
    • Russ Cox's avatar
      runtime: give nosplit functions 32 more bytes of headroom · fe91006a
      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
      fe91006a
    • Brad Fitzpatrick's avatar
      runtime: restore header to first goroutine in Stack · 9a5654ab
      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
      9a5654ab
    • Russ Cox's avatar
      cmd/cc, runtime: convert C compilers to use Go calling convention · 25f6b02a
      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
      25f6b02a
    • Rick Hudson's avatar
      runtime: changes to g->atomicstatus (nee status) to support concurrent GC · 0a7c7ac8
      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
      0a7c7ac8
    • Russ Cox's avatar
      CONTRIBUTORS: add Rick Hudson (Google CLA) · 56f8b297
      Russ Cox authored
      TBR=rlh
      CC=golang-codereviews
      https://golang.org/cl/131410043
      56f8b297
    • Dave Cheney's avatar
      cmd/gc: fix undefined behaviour warnings in mparith3.c · 9c504696
      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
      9c504696
  3. 26 Aug, 2014 11 commits
  4. 25 Aug, 2014 2 commits