1. 08 Jul, 2018 2 commits
    • Austin Clements's avatar
      runtime: fix TestAbort on non-x86 arches · 5cb1b177
      Austin Clements authored
      CL 122515 tightened TestAbort to look for breakpoint exceptions and
      not just general signal crashes, but this only applies on x86 arches.
      On non-x86 arches we use a nil pointer dereference to abort, so the
      test is now failing.
      
      This CL re-loosens TestAbort on non-x86 arches to only expect a signal
      traceback.
      
      Should fix the build on linux/arm, linux/arm64, linux/ppc64, and
      linux/s390x.
      
      Change-Id: I1065341180ab5ab4da63b406c641dcde93c9490b
      Reviewed-on: https://go-review.googlesource.com/122580
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      5cb1b177
    • David du Colombier's avatar
      runtime: fix TestAbort on Plan 9 · b001ffb8
      David du Colombier authored
      Since CL 122515, TestAbort is failing on Plan 9
      because there is no SIGTRAP signal on Plan 9,
      but a note containing the "sys: breakpoint" string.
      
      This change fixes the TestAbort test by handling
      the Plan 9 case.
      
      Fixes #26265.
      
      Change-Id: I2fae00130bcee1cf946d8cc9d147a77f951be390
      Reviewed-on: https://go-review.googlesource.com/122464
      Run-TryBot: David du Colombier <0intro@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarAustin Clements <austin@google.com>
      b001ffb8
  2. 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: default avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: default 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: default avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: default 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: default avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: default 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: default avatarKeith Randall <khr@golang.org>
      f5d48631
  3. 06 Jul, 2018 11 commits
  4. 05 Jul, 2018 3 commits
  5. 04 Jul, 2018 4 commits
  6. 03 Jul, 2018 11 commits
  7. 02 Jul, 2018 5 commits