An error occurred fetching the project authors.
  1. 04 Sep, 2015 1 commit
  2. 03 Sep, 2015 11 commits
  3. 02 Sep, 2015 5 commits
  4. 01 Sep, 2015 8 commits
  5. 31 Aug, 2015 11 commits
  6. 30 Aug, 2015 4 commits
    • Shenghou Ma's avatar
      net: add -lsendfile to cgo LDFLAGS for solaris · 5f2c420e
      Shenghou Ma authored
      Fixes external linking of net/http tests (or anything that uses
      sendfile).
      
      Fixes #12390.
      
      Change-Id: Iee08998cf66e7b0ce851db138a00ebae6dc2395e
      Reviewed-on: https://go-review.googlesource.com/14072Reviewed-by: default avatarDave Cheney <dave@cheney.net>
      Reviewed-by: default avatarAram Hăvărneanu <aram@mgk.ro>
      5f2c420e
    • Austin Clements's avatar
      runtime: check that stack barrier unwind is in sync · 77e52829
      Austin Clements authored
      Currently the stack barrier stub blindly unwinds the next stack
      barrier from the G's stack barrier array without checking that it's
      the right stack barrier. If through some bug the stack barrier array
      position gets out of sync with where we actually are on the stack,
      this could return to the wrong PC, which would lead to difficult to
      debug crashes. To address this, this commit adds a check to the amd64
      stack barrier stub that it's unwinding the correct stack barrier.
      
      Updates #12238.
      
      Change-Id: If824d95191d07e2512dc5dba0d9978cfd9f54e02
      Reviewed-on: https://go-review.googlesource.com/13948Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      77e52829
    • Austin Clements's avatar
      runtime: add GODEBUG for stack barriers at every frame · 3bfc9df2
      Austin Clements authored
      Currently enabling the debugging mode where stack barriers are
      installed at every frame requires recompiling the runtime. However,
      this is potentially useful for field debugging and for runtime tests,
      so make this mode a GODEBUG.
      
      Updates #12238.
      
      Change-Id: I6fb128f598b19568ae723a612e099c0ed96917f5
      Reviewed-on: https://go-review.googlesource.com/13947Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      3bfc9df2
    • Austin Clements's avatar
      runtime: don't install a stack barrier in cgocallback_gofunc's frame · e2bb03f1
      Austin Clements authored
      Currently the runtime can install stack barriers in any frame.
      However, the frame of cgocallback_gofunc is special: it's the one
      function that switches from a regular G stack to the system stack on
      return. Hence, the return PC slot in its frame on the G stack is
      actually used to save getg().sched.pc (so tracebacks appear to unwind
      to the last Go function running on that G), and not as an actual
      return PC for cgocallback_gofunc.
      
      Because of this, if we install a stack barrier in cgocallback_gofunc's
      return PC slot, when cgocallback_gofunc does return, it will move the
      stack barrier stub PC in to getg().sched.pc and switch back to the
      system stack. The rest of the runtime doesn't know how to deal with a
      stack barrier stub in sched.pc: nothing knows how to match it up with
      the G's stack barrier array and, when the runtime removes stack
      barriers, it doesn't know to undo the one in sched.pc. Hence, if the C
      code later returns back in to Go code, it will attempt to return
      through the stack barrier saved in sched.pc, which may no longer have
      correct unwinding information.
      
      Fix this by blacklisting cgocallback_gofunc's frame so the runtime
      won't install a stack barrier in it's return PC slot.
      
      Fixes #12238.
      
      Change-Id: I46aa2155df2fd050dd50de3434b62987dc4947b8
      Reviewed-on: https://go-review.googlesource.com/13944Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      e2bb03f1