Skip to content
Permalink
Branch: master
Commits on Feb 25, 2020
  1. cmd/link: improve gap detection in TestPIESize

    cherrymui committed Feb 24, 2020
    In CL 210180 we detect gaps between PT_LOAD segments and subtract
    them from size calculation. The code there only works when
    PT_LOAD segments are next to each other. But it is possible that
    there are other segments in between (e.g. a GNU_RELRO segment).
    Relax the gap detection to count gaps between PT_LOAD segments
    regardless of whether they are next to each other.
    
    Updates #36023.
    Updates #35545.
    
    Change-Id: I8b94506359fa649a4478acc742d86d4b16022dbc
    Reviewed-on: https://go-review.googlesource.com/c/go/+/220654
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Than McIntosh <thanm@google.com>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
Commits on Feb 21, 2020
  1. cmd/dist: test cgo internal linking PIE

    cherrymui committed Feb 9, 2020
    On platforms where internal linking PIE is supported, run
    misc/cgo/test with that configuration.
    
    Change-Id: Ia09631b07cc469c85818e1494093d802ea9d69a1
    Reviewed-on: https://go-review.googlesource.com/c/go/+/218838
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
  2. cmd/link: also apply R_ADDR relocation statically when internal linki…

    cherrymui committed Feb 11, 2020
    …ng PIE
    
    When internal linking PIE, R_ADDR relocations cannot be resolved
    statically so we generate dynamic relocations for it. We don't
    apply the relocations statically, so the bytes in the file are
    left unset (likely zero). This makes some tool that examines the
    file statically, e.g. go version, to fail to find the referenced
    addresses.
    
    This CL makes the linker also apply the relocations to the file
    content, so it holds the correct offsets and so can be examined
    statically.
    
    Fixes #37173.
    
    Change-Id: Ia5c6b661f1a91a232843ca4224264bfd7a5509eb
    Reviewed-on: https://go-review.googlesource.com/c/go/+/219199
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
  3. cmd/link: handle absolute address relocation in C objects for interna…

    cherrymui committed Feb 9, 2020
    …l linking PIE
    
    For an absolute address relocation in C objects (e.g.
    R_X86_64_64), we turn it into an R_ADDR relocation and handle it
    the same way. For internal linking PIE, this R_ADDR relocation
    cannot be resolved statically. We need to generate a dynamic
    relocation for it. This CL makes it so.
    
    This fixes internal linking PIE on the dev.boringcrypto branch.
    Test will be enabled in the next CL.
    
    Change-Id: I9bdd6517ccd79cbbe9c64844a31536bf3da37616
    Reviewed-on: https://go-review.googlesource.com/c/go/+/218837
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
Commits on Feb 18, 2020
  1. cmd/link, runtime: skip holes in func table

    cherrymui committed Feb 16, 2020
    On PPC64 when external linking, for large binaries we split the
    text section to multiple sections, so the external linking may
    insert trampolines between sections. These trampolines are within
    the address range covered by the func table, but not known by Go.
    This causes runtime.findfunc to return a wrong function if the
    given PC is from such trampolines.
    
    In this CL, we generate a marker between text sections where
    there could potentially be a hole in the func table. At run time,
    we skip the hole if we see such a marker.
    
    Fixes #37216.
    
    Change-Id: I95ab3875a84b357dbaa65a4ed339a19282257ce0
    Reviewed-on: https://go-review.googlesource.com/c/go/+/219717
    Reviewed-by: David Chase <drchase@google.com>
Commits on Feb 13, 2020
  1. runtime: correct caller PC/SP offsets in walltime1/nanotime1

    cherrymui committed Feb 11, 2020
    In walltime1/nanotime1, we save the caller's PC and SP for stack
    unwinding. The code does that assumed zero frame size. Now that
    the frame size is not zero, correct the offset. Rewrite it in a
    way that doesn't depend on hard-coded frame size.
    
    May fix #37127.
    
    Change-Id: I47d6d54fc3499d7d5946c3f6a2dbd24fbd679de1
    Reviewed-on: https://go-review.googlesource.com/c/go/+/219118
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Austin Clements <austin@google.com>
  2. runtime: zero upper bit of Y registers in asyncPreempt on darwin/amd64

    cherrymui committed Feb 11, 2020
    Apparently, the signal handling code path in darwin kernel leaves
    the upper bits of Y registers in a dirty state, which causes many
    SSE operations (128-bit and narrower) become much slower. Clear
    the upper bits to get to a clean state.
    
    We do it at the entry of asyncPreempt, which is immediately
    following exiting from the kernel's signal handling code, if we
    actually injected a call. It does not cover other exits where we
    don't inject a call, e.g. failed preemption, profiling signal, or
    other async signals. But it does cover an important use case of
    async signals, preempting a tight numerical loop, which we
    introduced in this cycle.
    
    Running the benchmark in issue #37174:
    
    name    old time/op  new time/op  delta
    Fast-8  90.0ns ± 1%  46.8ns ± 3%  -47.97%  (p=0.000 n=10+10)
    Slow-8   188ns ± 5%    49ns ± 1%  -73.82%  (p=0.000 n=10+9)
    
    There is no more slowdown due to preemption signals.
    
    For #37174.
    
    Change-Id: I8b83d083fade1cabbda09b4bc25ccbadafaf7605
    Reviewed-on: https://go-review.googlesource.com/c/go/+/219131
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Keith Randall <khr@golang.org>
Commits on Jan 27, 2020
  1. cmd/compile: on PPC64, fold offset into some loads/stores only when o…

    cherrymui committed Jan 24, 2020
    …ffset is 4-aligned
    
    On PPC64, MOVWload, MOVDload, and MOVDstore are assembled to a
    "DS from" instruction which requiers the offset is a multiple of
    4. Only fold offset to such instructions if it is a multiple of 4.
    
    Fixes #36723.
    
    "GOARCH=ppc64 GOOS=linux go build -gcflags=all=-d=ssa/check/on std cmd"
    passes now.
    
    Change-Id: I67f2a6ac02f0d33d470f68ff54936c289a4c765b
    Reviewed-on: https://go-review.googlesource.com/c/go/+/216379
    Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Commits on Jan 9, 2020
  1. runtime: overwrite asyncPreempt PC when injecting sigpanic on Windows

    cherrymui committed Jan 8, 2020
    On Windows, it might be possible that SuspendThread suspends a
    thread right between when an exception happens and when the
    exception handler runs. (This is my guess. I don't know the
    implementation detail of Windows exceptions to be sure.) In this
    case, we may inject a call to asyncPreempt before the exception
    handler runs. The exception handler will inject a sigpanic call,
    which will make the stack trace looks like
    
    sigpanic
    asyncPreempt
    actual panicking function
    
    i.e. it appears asyncPreempt panicked.
    
    Instead, just overwrite the PC, without pushing another frame.
    
    Fixes #35773.
    
    Change-Id: Ief4e964dcb7f45670b5f93c4dcf285cc1c737514
    Reviewed-on: https://go-review.googlesource.com/c/go/+/213879
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Austin Clements <austin@google.com>
Commits on Jan 6, 2020
  1. runtime: test memmove writes pointers atomically

    cherrymui committed Dec 27, 2019
    In the previous CL we ensures that memmove writes pointers
    atomically, so the concurrent GC won't observe a partially
    updated pointer. This CL adds a test.
    
    Change-Id: Icd1124bf3a15ef25bac20c7fb8933f1a642d897c
    Reviewed-on: https://go-review.googlesource.com/c/go/+/212627
    Reviewed-by: Austin Clements <austin@google.com>
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
Commits on Jan 4, 2020
  1. runtime: don't use R11 in nanotime1/walltime1 on ARM

    cherrymui committed Dec 30, 2019
    R11 a.k.a. REGTMP is the temp register used by the assembler. It
    may be clobbered if the assembler needs to synthesize
    instructions. In particular, in nanotime1/walltime1, the load of
    global variable runtime.iscgo clobbers it. So, avoid using R11
    to hold a long-lived value.
    
    Fixes #36309.
    
    Change-Id: Iec2ab9d664532cad8fbf58da17f580e64a744f62
    Reviewed-on: https://go-review.googlesource.com/c/go/+/212641
    Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
    Reviewed-by: Andrew G. Morgan <agm@google.com>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
    Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
Commits on Jan 2, 2020
  1. runtime: ensure memmove write pointer atomically on ARM64

    cherrymui committed Dec 27, 2019
    If a pointer write is not atomic, if the GC is running
    concurrently, it may observe a partially updated pointer, which
    may point to unallocated or already dead memory. Most pointer
    writes, like the store instructions generated by the compiler,
    are already atomic. But we still need to be careful in places
    like memmove. In memmove, we don't know which bits are pointers
    (or too expensive to query), so we ensure that all aligned
    pointer-sized units are written atomically.
    
    Fixes #36101.
    
    Change-Id: I1b3ca24c6b1ac8a8aaf9ee470115e9a89ec1b00b
    Reviewed-on: https://go-review.googlesource.com/c/go/+/212626
    Reviewed-by: Austin Clements <austin@google.com>
Commits on Dec 18, 2019
  1. runtime: use innermost frame's func name for async preemption check

    cherrymui committed Dec 18, 2019
    We don't asynchronously preempt if we are in the runtime. We do
    this by checking the function name. However, it failed to take
    inlining into account. If a runtime function gets inlined into
    a non-runtime function, it can be preempted, and bad things can
    happen. One instance of this is dounlockOSThread inlined into
    UnlockOSThread which is in turn inlined into a non-runtime
    function.
    
    Fix this by using the innermost frame's function name.
    
    Change-Id: Ifa036ce1320700aaaefd829b4bee0d04d05c395d
    Reviewed-on: https://go-review.googlesource.com/c/go/+/211978
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Austin Clements <austin@google.com>
Commits on Dec 13, 2019
  1. runtime: fix off-by-1 error on address ranges

    cherrymui committed Dec 12, 2019
    When growing the address ranges, the new length is the old length + 1.
    
    Fixes #36113.
    
    Change-Id: I1b425f78e473cfa3cbdfe6113e166663f41fc9f3
    Reviewed-on: https://go-review.googlesource.com/c/go/+/211157
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Michael Knyszek <mknyszek@google.com>
Commits on Dec 11, 2019
  1. test: add a test for gccgo compiler bug of missing type descriptor

    cherrymui committed Dec 11, 2019
    The gccgo compiler did not generate type descriptor for a pointer
    to a type alias defined in another package, causing linking error.
    The fix is CL 210787. This CL adds a test.
    
    Updates #36085.
    
    Change-Id: I3237c7fedb4d92fb2dc610ee2b88087f96dc2a1a
    Reviewed-on: https://go-review.googlesource.com/c/go/+/210858
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
Commits on Dec 6, 2019
  1. cmd/link: skip gaps between PT_LOAD segments in TestPIESize

    cherrymui committed Dec 6, 2019
    There may be gaps between non-writeable and writeable PT_LOAD
    segments, and the gaps may be large as the segments may have
    large alignment. Don't count those gaps in file size comparison.
    
    Fixes #36023.
    
    Change-Id: I68582bdd0f385ac5c6f87d485d476d06bc96db19
    Reviewed-on: https://go-review.googlesource.com/c/go/+/210180
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: David Chase <drchase@google.com>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
  2. cmd/compile: mark empty block preemptible

    cherrymui committed Dec 3, 2019
    Currently, a block's control instruction gets the liveness info
    of the last Value in the block. However, for an empty block, the
    control instruction gets the invalid liveness info and therefore
    not preemptible. One example is empty infinite loop, which has
    only a control instruction. The control instruction being non-
    preemptible makes the whole loop non-preemptible.
    
    Fix this by using a different, preemptible liveness info for
    empty block's control. We can choose an arbitrary preemptible
    liveness info, as at run time we don't really use the liveness
    map at that instruction.
    
    As before, if the last Value in the block is non-preemptible, so
    is the block control. For example, the conditional branch in the
    write barrier test block is still non-preemptible.
    
    Also, only update liveness info if we are actually emitting
    instructions. So zero-width Values' liveness info (which are
    always invalid) won't affect the block control's liveness info.
    For example, if the last Values in a block is a tuple-generating
    operation and a Select, the block control instruction is still
    preemptible.
    
    Fixes #35923.
    
    Change-Id: Ic5225f3254b07e4955f7905329b544515907642b
    Reviewed-on: https://go-review.googlesource.com/c/go/+/209659
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    Reviewed-by: David Chase <drchase@google.com>
  3. cmd/compile: don't fuse branches with side effects

    cherrymui committed Dec 5, 2019
    Count Values with side effects but no use as live, and don't fuse
    branches that contain such Values. (This can happen e.g. when it
    is followed by an infinite loop.) Otherwise this may lead to
    miscompilation (side effect fired at wrong condition) or ICE (two
    stores live simultaneously).
    
    Fixes #36005.
    
    Change-Id: If202eae4b37cb7f0311d6ca120ffa46609925157
    Reviewed-on: https://go-review.googlesource.com/c/go/+/210179
    Reviewed-by: Keith Randall <khr@golang.org>
Commits on Nov 27, 2019
  1. runtime: print more information on stack overflow

    cherrymui committed Nov 15, 2019
    Print the current SP and (old) stack bounds when the stack grows
    too large. This helps to identify the problem: whether a large
    stack is used, or something else goes wrong.
    
    For #35470.
    
    Change-Id: I34a4064d5c7280978391d835e171b90d06f87222
    Reviewed-on: https://go-review.googlesource.com/c/go/+/207351
    Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
  2. cmd/internal/obj: mark split-stack prologue nonpreemptible

    cherrymui committed Nov 15, 2019
    When there are both a synchronous preemption request (by
    clobbering the stack guard) and an asynchronous one (by signal),
    the running goroutine may observe the synchronous request first
    in stack bounds check, and go to the path of calling morestack.
    If the preemption signal arrives at this point before the call to
    morestack, the goroutine will be asynchronously preempted,
    entering the scheduler. When it is resumed, the scheduler clears
    the preemption request, unclobbers the stack guard. But the
    resumed goroutine will still call morestack, as it is already on
    its way. morestack will, as there is no preemption request,
    double the stack unnecessarily. If this happens multiple times,
    the stack may grow too big, although only a small amount is
    actually used.
    
    To fix this, we mark the stack bounds check and the call to
    morestack async-nonpreemptible, starting after the memory
    instruction (mostly a load, on x86 CMP with memory).
    
    Not done for Wasm as it does not support async preemption.
    
    Fixes #35470.
    
    Change-Id: Ibd7f3d935a3649b80f47539116ec9b9556680cf2
    Reviewed-on: https://go-review.googlesource.com/c/go/+/207350
    Reviewed-by: David Chase <drchase@google.com>
  3. cmd/internal/obj, runtime: use register map to mark unsafe points

    cherrymui committed Nov 14, 2019
    Currently we use stack map index -2 to mark unsafe points, i.e.
    PC ranges that is not safe for async preemption. This has a
    problem: it cannot mark CALL instructions, because for stack scan
    a valid stack map index is needed.
    
    This CL switches to use register map index for marking unsafe
    points instead, which does not conflict with stack scan and can
    be applied on CALL instructions. This is necessary as next CL
    will mark call to morestack nonpreemptible.
    
    For #35470.
    
    Change-Id: I357bf26c996e1fee1e7eebe4e6bb07d62930d3f7
    Reviewed-on: https://go-review.googlesource.com/c/go/+/207349
    Reviewed-by: David Chase <drchase@google.com>
Commits on Nov 26, 2019
  1. runtime: disable async preemption on darwin/arm(64) if no cgo

    cherrymui committed Nov 26, 2019
    On darwin, we use libc calls, and cgo is required on ARM and
    ARM64 so we have TLS set up to save/restore G during C calls. If
    cgo is absent, we cannot save/restore G in TLS, and if a signal
    is received during C execution we cannot get the G. Therefore
    don't send signals (and hope that we won't receive any signal
    during C execution).
    
    This can only happen in the go_bootstrap program (otherwise cgo
    is required).
    
    Fixes #35800.
    
    Change-Id: I6c02a9378af02c19d32749a42db45165b578188d
    Reviewed-on: https://go-review.googlesource.com/c/go/+/208818
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
Commits on Nov 21, 2019
  1. runtime: relax TestAsyncPreempt

    cherrymui committed Nov 19, 2019
    In TestAsyncPreempt, the function being tested for preemption,
    although still asynchronously preemptible, may have only samll
    ranges of PCs that are preemtible. In an unlucky run, it may
    take quite a while to have a signal that lands on a preemptible
    instruction. The test case is kind of an extreme. Relax it to
    make it more preemptible.
    
    In the original version, the first closure has more work to do,
    and it is not a leaf function, and the second test case is a
    frameless leaf function. In the current version, the first one
    is also a frameless leaf function (the atomic is intrinsified).
    Add some calls to it. It is still not preemptible without async
    preemption.
    
    Fixes #35608.
    
    Change-Id: Ia4f857f2afc55501c6568d7507b517e3b4db191c
    Reviewed-on: https://go-review.googlesource.com/c/go/+/208221
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
Commits on Nov 18, 2019
  1. runtime: always use Go signal stack in non-cgo program

    cherrymui committed Nov 16, 2019
    When initializing an M, we set up its signal stack to the gsignal
    stack if an alternate signal stack is not already set. On Android,
    an alternate signal stack is always set, even cgo is not used.
    This breaks the logic of saving/fetching G on the signal stack
    during VDSO, which assumes the signal stack is allocated by Go if
    cgo is not used (if cgo is used, we use TLS for saving G).
    
    When cgo is not used, we can always use the Go signal stack, even
    if an alternate signal stack is already set. Since cgo is not
    used, no one other than the Go runtime will care.
    
    Fixes #35554.
    
    Change-Id: Ia9d84cd55cb35097f3df46f37996589c86f10e0f
    Reviewed-on: https://go-review.googlesource.com/c/go/+/207445
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
Commits on Nov 15, 2019
  1. cmd/internal/obj/x86: mark 2-instruction TLS access nonpreemptible

    cherrymui committed Nov 13, 2019
    The 2-instruction TLS access sequence
    	MOVQ TLS, BX
    	MOVQ 0(BX)(TLS*1), BX
    is not async preemptible, as if it is preempted and resumed on a
    different thread, the TLS address may become invalid.
    
    May fix #35349. (This is a rare failure and I haven't been able
    to reproduce it.)
    
    Change-Id: Ie1a366fd0d7d73627dc62ee2de01c0aa09365f2b
    Reviewed-on: https://go-review.googlesource.com/c/go/+/206903
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    Reviewed-by: Austin Clements <austin@google.com>
  2. runtime: crash if a signal is received with bad G and no extra M

    cherrymui committed Nov 14, 2019
    When we receive a signal, if G is nil we call badsignal, which
    calls needm. When cgo is not used, there is no extra M, so needm
    will just hang. In this situation, even GOTRACEBACK=crash cannot
    get a stack trace, as we're in the signal handler and cannot
    receive another signal (SIGQUIT).
    
    Instead, just crash.
    
    For #35554.
    Updates #34391.
    
    Change-Id: I061ac43fc0ac480435c050083096d126b149d21f
    Reviewed-on: https://go-review.googlesource.com/c/go/+/206959
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
Commits on Nov 12, 2019
  1. runtime: enable async preemption on darwin/arm64

    cherrymui committed Nov 11, 2019
    The problem should be fixed by the previous CL. Reenable async
    preemption on darwin/arm64.
    
    Updates #35439.
    
    Change-Id: I93e8c4702b4d8fe6abaa6fc9c27def5c8aed1b59
    Reviewed-on: https://go-review.googlesource.com/c/go/+/206419
    Reviewed-by: Keith Randall <khr@golang.org>
  2. cmd/internal/obj/arm64: save LR after decrementing SP on darwin

    cherrymui committed Nov 11, 2019
    iOS does not support SA_ONSTACK. The signal handler runs on the
    G stack. Any writes below the SP may be clobbered by the signal
    handler (even without call injection). So we save LR after
    decrementing SP on iOS.
    
    Updates #35439.
    
    Change-Id: Ia6d7a0669e0bcf417b44c031d2e26675c1184165
    Reviewed-on: https://go-review.googlesource.com/c/go/+/206418
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Keith Randall <khr@golang.org>
Commits on Nov 11, 2019
  1. runtime: don't save G during VDSO if we're handling signal

    cherrymui committed Nov 10, 2019
    On some platforms (currently ARM and ARM64), when calling into
    VDSO we store the G to the gsignal stack, if there is one, so if
    we receive a signal during VDSO we can find the G.
    
    If we receive a signal during VDSO, and within the signal handler
    we call nanotime again (e.g. when handling profiling signal),
    we'll save/clear the G slot on the gsignal stack again, which
    clobbers the original saved G. If we receive a second signal
    during the same VDSO execution, we will fetch a nil G, which will
    lead to bad things such as deadlock.
    
    Don't save G if we're calling VDSO code from the gsignal stack.
    Saving G is not necessary as we won't receive a nested signal.
    
    Fixes #35473.
    
    Change-Id: Ibfd8587a3c70c2f1533908b056e81b94d75d65a5
    Reviewed-on: https://go-review.googlesource.com/c/go/+/206397
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Bryan C. Mills <bcmills@google.com>
Commits on Nov 8, 2019
  1. cmd/internal/obj/arm64: make function epilogue async-signal safe

    cherrymui committed Nov 8, 2019
    When the frame size is large, we generate
    
    MOVD.P	0xf0(SP), LR
    ADD	$(framesize-0xf0), SP
    
    This is problematic: after the first instruction, we have a
    partial frame of size (framesize-0xf0). If we try to unwind the
    stack at this point, we'll try to read the LR from the stack at
    0(SP) (the new SP) as the frame size is not 0. But this slot does
    not contain a valid LR.
    
    Fix this by not changing SP in two instructions. Instead,
    generate
    
    MOVD	(SP), LR
    ADD	$framesize, SP
    
    This affects not only async preemption but also profiling. So we
    change the generated instructions, instead of marking unsafe
    point.
    
    Change-Id: I4e78c62d50ffc4acff70ccfbfec16a5ccae17f24
    Reviewed-on: https://go-review.googlesource.com/c/go/+/206057
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    TryBot-Result: Gobot Gobot <gobot@golang.org>
    Reviewed-by: Ian Lance Taylor <iant@golang.org>
  2. runtime: add async preemption support on PPC64

    cherrymui committed Oct 28, 2019
    This CL adds support of call injection and async preemption on
    PPC64.
    
    For the injected call to return to the preempted PC, we have to
    clobber either LR or CTR. For reasons mentioned in previous CLs,
    we choose CTR. Previous CLs have marked code sequences that use
    CTR async-nonpreemtible.
    
    Change-Id: Ia642b5f06a890dd52476f45023b2a830c522eee0
    Reviewed-on: https://go-review.googlesource.com/c/go/+/203824
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    Reviewed-by: Keith Randall <khr@golang.org>
Commits on Nov 7, 2019
  1. runtime: disable async preemption on darwin/arm(64) for now

    cherrymui committed Nov 7, 2019
    Enabling async preemption on darwin/arm and darwin/arm64 causes
    the builder to fail, e.g.
    https://build.golang.org/log/03f727b8f91b0c75bf54ff508d7d2f00b5cad4bf
    
    Due to the limited resource, I haven't been able to get access on
    those devices to debug. Disable async preemption for now.
    
    Updates #35439.
    
    Change-Id: I5a31ad6962c2bae8e6e9b8303c494610a8a4e50a
    Reviewed-on: https://go-review.googlesource.com/c/go/+/205842
    Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
  2. runtime: add async preemption support on MIPS and MIPS64

    cherrymui committed Oct 27, 2019
    This CL adds support of call injection and async preemption on
    MIPS and MIPS64.
    
    Like ARM64, we need to clobber one register (REGTMP) for
    returning from the injected call. Previous CLs have marked code
    sequences that use REGTMP async-nonpreemtible.
    
    It seems on MIPS/MIPS64, a CALL instruction is not "atomic" (!).
    If a signal is delivered right at the CALL instruction, we may
    see an updated LR with a not-yet-updated PC. In some cases this
    may lead to failed stack unwinding. Don't preempt in this case.
    
    Change-Id: I99437b2d05869ded5c0c8cb55265dbfc933aedab
    Reviewed-on: https://go-review.googlesource.com/c/go/+/203720
    Reviewed-by: Keith Randall <khr@golang.org>
  3. runtime: add async preemption support on S390X

    cherrymui committed Oct 30, 2019
    This CL adds support of call injection and async preemption on
    S390X.
    
    Like ARM64, we need to clobber one register (REGTMP) for
    returning from the injected call. Previous CLs have marked code
    sequences that use REGTMP async-nonpreemtible.
    
    Change-Id: I78adbc5fd70ca245da390f6266623385b45c9dfc
    Reviewed-on: https://go-review.googlesource.com/c/go/+/204106
    Reviewed-by: Keith Randall <khr@golang.org>
  4. cmd/internal/obj/s390x: mark unsafe points

    cherrymui committed Oct 30, 2019
    For async preemption, we will be using REGTMP as a temporary
    register in injected call on S390X, which will clobber it. So any
    code that uses REGTMP is not safe for async preemption.
    
    In the assembler backend, we expand a Prog to multiple machine
    instructions and use REGTMP as a temporary register if necessary.
    These need to be marked unsafe. Unlike ARM64 and MIPS,
    instructions on S390X are variable length so we don't use the
    length as a condition. Instead, we set a bit on the Prog whenever
    REGTMP is used.
    
    Change-Id: Ie5d14068a950f4c7cea51dff2c4a8bdc19ec9348
    Reviewed-on: https://go-review.googlesource.com/c/go/+/204105
    Run-TryBot: Cherry Zhang <cherryyz@google.com>
    Reviewed-by: Keith Randall <khr@golang.org>
Older
You can’t perform that action at this time.