1. 09 Jul, 2018 11 commits
  2. 08 Jul, 2018 3 commits
  3. 07 Jul, 2018 4 commits
    • Austin Clements's avatar
      runtime: handle g0 stack overflows gracefully · 78561c4a
      Austin Clements authored
      Currently, if the runtime overflows the g0 stack on Windows, it leads
      to an infinite recursion:
      
      1. Something overflows the g0 stack bounds and calls morestack.
      
      2. morestack determines it's on the g0 stack and hence cannot grow the
      stack, so it calls badmorestackg0 (which prints "fatal: morestack on
      g0") followed by abort.
      
      3. abort performs an INT $3, which turns into a Windows
      _EXCEPTION_BREAKPOINT exception.
      
      4. This enters the Windows sigtramp, which ensures we're on the g0
      stack and calls exceptionhandler.
      
      5. exceptionhandler has a stack check prologue, so it determines that
      it's out of stack and calls morestack.
      
      6. goto 2
      
      Fix this by making the exception handler avoid stack checks until it
      has ruled out an abort and by blowing away the stack bounds in
      lastcontinuehandler before we print the final fatal traceback (which
      itself involves a lot of stack bounds checks).
      
      Fixes #21382.
      
      Change-Id: Ie66e91f708e18d131d97f22b43f9ac26f3aece5a
      Reviewed-on: https://go-review.googlesource.com/120857
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: 's avatarAlex Brainman <alex.brainman@gmail.com>
      78561c4a
    • Austin Clements's avatar
      runtime: account for guard zone in Windows stack size · d6b56bb3
      Austin Clements authored
      Windows includes an 8K guard in system-allocated thread stacks, which
      we currently don't account for when setting the g0 stack bounds. As a
      result, if we do overflow the g0 stack bounds, we'll get a
      STATUS_GUARD_PAGE_VIOLATION exception, which we're not expecting.
      
      Fix the g0 stack bounds to include a total of 16K of slop to account
      for this 8K guard.
      
      Updates #21382.
      
      Change-Id: Ia89b741b1413328e4681a237f5a7ee645531fe16
      Reviewed-on: https://go-review.googlesource.com/122516
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: 's avatarAlex Brainman <alex.brainman@gmail.com>
      d6b56bb3
    • Austin Clements's avatar
      runtime: fix abort handling on Windows · 7001ac53
      Austin Clements authored
      On Windows, the IP recorded in the breakpoint exception caused by
      runtime.abort is actually one byte after the INT3, unlike on UNIX
      OSes. Account for this in isgoexception.
      
      It turns out TestAbort was "passing" on Windows anyway because abort
      still caused a fatal panic, just not the one we were expecting. This
      CL tightens this test to check that the runtime specifically reports a
      breakpoint exception.
      
      Fixing this is related to #21382, since we use runtime.abort in
      reporting g0 stack overflows, and it's important that we detect this
      and not try to handle it.
      
      Change-Id: I66120944d138eb80f839346b157a3759c1019e34
      Reviewed-on: https://go-review.googlesource.com/122515
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: 's avatarAlex Brainman <alex.brainman@gmail.com>
      7001ac53
    • Ben Shi's avatar
      cmd/compile: fix a bug in 386 backend · f5d48631
      Ben Shi authored
      The ADDLmodify/SUBLmodify/ANDLmodify/ORLmodify/XORLmodify should
      have clobberFlags set to true.
      
      Change-Id: Ie447d536db51334eddc70c00a722647282186a69
      Reviewed-on: https://go-review.googlesource.com/122556
      Run-TryBot: Ben Shi <powerman1st@163.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      f5d48631
  4. 06 Jul, 2018 11 commits
  5. 05 Jul, 2018 3 commits
  6. 04 Jul, 2018 4 commits
  7. 03 Jul, 2018 4 commits
    • Paul Jolly's avatar
      misc/wasm: use single map for string, symbol and object id mapping. · abaf53fb
      Paul Jolly authored
      Currently we use a globally unique symbol property on objects that get
      passed from JavaScript to Go to store a unique ID that Go then uses when
      referring back to the JavaScript object (via js.Value.ref). This
      approach fails however when a JavaScript object cannot be modified, i.e.
      cannot have new properties added or is frozen. The test that is added as
      part of this commit currently fails with:
      
        Cannot add property Symbol(), object is not extensible
      
      Instead we consolidate the string, symbol and object unique ID mapping
      into a single map. Map key equality is determined via strict equality,
      which is the semantic we want in this situation.
      
      Change-Id: Ieb2b50fc36d3c30e148aa7a41557f3c59cd33766
      Reviewed-on: https://go-review.googlesource.com/121799
      Run-TryBot: Paul Jolly <paul@myitcv.org.uk>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRichard Musiol <neelance@gmail.com>
      abaf53fb
    • Agniva De Sarker's avatar
      cmd/dist: skip building tools for js/wasm · 5d4f0474
      Agniva De Sarker authored
      Fixes #25911
      
      Change-Id: Id3b5ea5494544e9e7f889831cefaf080cae8865d
      Reviewed-on: https://go-review.googlesource.com/120655Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      5d4f0474
    • Daniel Martí's avatar
      cmd/compile: reorganise and improve ssa/README.md · aad71d31
      Daniel Martí authored
      Since the initial version was written, I've gotten help writing
      cmd/compile/README.md and I've also learned some more on my own, so it's
      time to organise this document better and expand it.
      
      First, split up the document in sections, starting from the simplest
      ideas that can be explained on their own. From there, build all the way
      up into SSA functions and how they are compiled.
      
      Each of the sections also gets more detail now; most ideas that were a
      paragraph are now a section with several paragraphs. No new major
      sections have been added in this CL.
      
      While at it, add a copyright notice and make better use of markdown,
      just like in the other README.md.
      
      Also fix a file path in value.go, which I noticed to be stale while
      reading godocs to write the document.
      
      Finally, leave a few TODO comments for areas that would benefit from
      extra input from people familiar with the SSA package. They will be
      taken care of in future CLs.
      
      Change-Id: I85e7a69a0b3260e72139991a625d926099624f71
      Reviewed-on: https://go-review.googlesource.com/110067Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      aad71d31
    • Tobias Klauser's avatar
      cmd/internal/obj: follow convention for generated code comment · 2ee6bfbd
      Tobias Klauser authored
      Follow the convertion (https://golang.org/s/generatedcode) for generated
      code in stringer.go.
      
      Change-Id: I7b5fbb04ba03e8ac77a9a0a402088669469de858
      Reviewed-on: https://go-review.googlesource.com/122015
      Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      2ee6bfbd