qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-11-08 19:36:22 -07:00
Code Releases Activity
b7f4307761
go/misc/cgo/test/testdata/issue9400/asm_386.s

28 lines
574 B
ArmAsm
Raw Normal View History

all: make copyright headers consistent with one space after period Follows suit with https://go-review.googlesource.com/#/c/20111. Generated by running $ grep -R 'Go Authors. All' * | cut -d":" -f1 | while read F;do perl -pi -e 's/Go Authors. All/Go Authors. All/g' $F;done The code in cmd/internal/unvendor wasn't changed. Fixes #15213 Change-Id: I4f235cee0a62ec435f9e8540a1ec08ae03b1a75f Reviewed-on: https://go-review.googlesource.com/21819 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-04-10 15:32:26 -06:00
// Copyright 2014 The Go Authors. All rights reserved.
misc/cgo/test/issue9400: fix to build with gccgo This doesn't test much with gccgo, but at least it builds now, and the test does, unsurprisingly, pass. A proper test would require adding assembly files in GCC syntax for all platforms that gccgo supports, which would be infeasible. Also added copyright headers to the asm files. Change-Id: Icea5af29d7d521a0681506ddb617a79705b76d33 Reviewed-on: https://go-review.googlesource.com/9417 Reviewed-by: Minux Ma <minux@golang.org>
2015-04-28 18:58:17 -06:00
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
all: use more precise build tags s/!gccgo/gc/ in files which use gc-syntax assembly. Change-Id: Ifdadb62edd1210ebc70e7cd415648b752afaf067 Reviewed-on: https://go-review.googlesource.com/c/go/+/269957 Reviewed-by: Than McIntosh <thanm@google.com> Trust: David Chase <drchase@google.com> Trust: Matthew Dempsky <mdempsky@google.com>
2020-11-12 15:42:58 -07:00
// +build gc
misc/cgo/test/issue9400: fix to build with gccgo This doesn't test much with gccgo, but at least it builds now, and the test does, unsurprisingly, pass. A proper test would require adding assembly files in GCC syntax for all platforms that gccgo supports, which would be infeasible. Also added copyright headers to the asm files. Change-Id: Icea5af29d7d521a0681506ddb617a79705b76d33 Reviewed-on: https://go-review.googlesource.com/9417 Reviewed-by: Minux Ma <minux@golang.org>
2015-04-28 18:58:17 -06:00
runtime: run libc SIGSETXID and SIGCANCEL handlers on signal stack These signals are used by glibc to broadcast setuid/setgid to all threads and to send pthread cancellations. Unlike other signals, the Go runtime does not intercept these because they must invoke the libc handlers (see issues #3871 and #6997). However, because 1) these signals may be issued asynchronously by a thread running C code to another thread running Go code and 2) glibc does not set SA_ONSTACK for its handlers, glibc's signal handler may be run on a Go stack. Signal frames range from 1.5K on amd64 to many kilobytes on ppc64, so this may overflow the Go stack and corrupt heap (or other stack) data. Fix this by ensuring that these signal handlers have the SA_ONSTACK flag (but not otherwise taking over the handler). This has been a problem since Go 1.1, but it's likely that people haven't encountered it because it only affects setuid/setgid and pthread_cancel. Fixes #9600. Change-Id: I6cf5f5c2d3aa48998d632f61f1ddc2778dcfd300 Reviewed-on: https://go-review.googlesource.com/1887 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2014-12-19 14:16:17 -07:00
#include "textflag.h"
TEXT ·RewindAndSetgid(SB),NOSPLIT,$0-0
misc/cgo/test: fix issue9400 test on android/386 The test for #9400 relies on an assembler function that manipulates the stack pointer. Meanwile, it uses a global variable for synchronization. However, position independent code on 386 use a function call to fetch the base address for global variables. That function call in turn overwrites the Go stack. Fix that by fetching the global variable address once before the stack register manipulation. Fixes the android/386 builder. Change-Id: Ib77bd80affaa12f09d582d09d8b84a73bd021b60 Reviewed-on: https://go-review.googlesource.com/23683 Run-TryBot: Elias Naur <elias.naur@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-06-02 07:00:34 -06:00
MOVL $·Baton(SB), BX
runtime: run libc SIGSETXID and SIGCANCEL handlers on signal stack These signals are used by glibc to broadcast setuid/setgid to all threads and to send pthread cancellations. Unlike other signals, the Go runtime does not intercept these because they must invoke the libc handlers (see issues #3871 and #6997). However, because 1) these signals may be issued asynchronously by a thread running C code to another thread running Go code and 2) glibc does not set SA_ONSTACK for its handlers, glibc's signal handler may be run on a Go stack. Signal frames range from 1.5K on amd64 to many kilobytes on ppc64, so this may overflow the Go stack and corrupt heap (or other stack) data. Fix this by ensuring that these signal handlers have the SA_ONSTACK flag (but not otherwise taking over the handler). This has been a problem since Go 1.1, but it's likely that people haven't encountered it because it only affects setuid/setgid and pthread_cancel. Fixes #9600. Change-Id: I6cf5f5c2d3aa48998d632f61f1ddc2778dcfd300 Reviewed-on: https://go-review.googlesource.com/1887 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2014-12-19 14:16:17 -07:00
// Rewind stack pointer so anything that happens on the stack
// will clobber the test pattern created by the caller
ADDL $(1024 * 8), SP
// Ask signaller to setgid
misc/cgo/test: fix issue9400 test on android/386 The test for #9400 relies on an assembler function that manipulates the stack pointer. Meanwile, it uses a global variable for synchronization. However, position independent code on 386 use a function call to fetch the base address for global variables. That function call in turn overwrites the Go stack. Fix that by fetching the global variable address once before the stack register manipulation. Fixes the android/386 builder. Change-Id: Ib77bd80affaa12f09d582d09d8b84a73bd021b60 Reviewed-on: https://go-review.googlesource.com/23683 Run-TryBot: Elias Naur <elias.naur@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-06-02 07:00:34 -06:00
MOVL $1, (BX)
runtime: run libc SIGSETXID and SIGCANCEL handlers on signal stack These signals are used by glibc to broadcast setuid/setgid to all threads and to send pthread cancellations. Unlike other signals, the Go runtime does not intercept these because they must invoke the libc handlers (see issues #3871 and #6997). However, because 1) these signals may be issued asynchronously by a thread running C code to another thread running Go code and 2) glibc does not set SA_ONSTACK for its handlers, glibc's signal handler may be run on a Go stack. Signal frames range from 1.5K on amd64 to many kilobytes on ppc64, so this may overflow the Go stack and corrupt heap (or other stack) data. Fix this by ensuring that these signal handlers have the SA_ONSTACK flag (but not otherwise taking over the handler). This has been a problem since Go 1.1, but it's likely that people haven't encountered it because it only affects setuid/setgid and pthread_cancel. Fixes #9600. Change-Id: I6cf5f5c2d3aa48998d632f61f1ddc2778dcfd300 Reviewed-on: https://go-review.googlesource.com/1887 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2014-12-19 14:16:17 -07:00
// Wait for setgid completion
loop:
PAUSE
misc/cgo/test: fix issue9400 test on android/386 The test for #9400 relies on an assembler function that manipulates the stack pointer. Meanwile, it uses a global variable for synchronization. However, position independent code on 386 use a function call to fetch the base address for global variables. That function call in turn overwrites the Go stack. Fix that by fetching the global variable address once before the stack register manipulation. Fixes the android/386 builder. Change-Id: Ib77bd80affaa12f09d582d09d8b84a73bd021b60 Reviewed-on: https://go-review.googlesource.com/23683 Run-TryBot: Elias Naur <elias.naur@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-06-02 07:00:34 -06:00
MOVL (BX), AX
runtime: run libc SIGSETXID and SIGCANCEL handlers on signal stack These signals are used by glibc to broadcast setuid/setgid to all threads and to send pthread cancellations. Unlike other signals, the Go runtime does not intercept these because they must invoke the libc handlers (see issues #3871 and #6997). However, because 1) these signals may be issued asynchronously by a thread running C code to another thread running Go code and 2) glibc does not set SA_ONSTACK for its handlers, glibc's signal handler may be run on a Go stack. Signal frames range from 1.5K on amd64 to many kilobytes on ppc64, so this may overflow the Go stack and corrupt heap (or other stack) data. Fix this by ensuring that these signal handlers have the SA_ONSTACK flag (but not otherwise taking over the handler). This has been a problem since Go 1.1, but it's likely that people haven't encountered it because it only affects setuid/setgid and pthread_cancel. Fixes #9600. Change-Id: I6cf5f5c2d3aa48998d632f61f1ddc2778dcfd300 Reviewed-on: https://go-review.googlesource.com/1887 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2014-12-19 14:16:17 -07:00
CMPL AX, $0
JNE loop
// Restore stack
SUBL $(1024 * 8), SP
RET
Copy Permalink