go/misc/cgo/test/cgo_linux_test.go

// Copyright 2012 The Go Authors.  All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

package cgotest

import "testing"

func TestSetgid(t *testing.T)  { testSetgid(t) }
func Test6997(t *testing.T)    { test6997(t) }
func TestBuildID(t *testing.T) { testBuildID(t) }
func Test9400(t *testing.T)    { test9400(t) }
misc/cgo/test: only run setgid test on GNU/Linux Fixes #3874. R=golang-dev, nj, r, minux.ma CC=golang-dev https://golang.org/cl/6446060 2012-07-28 11:40:51 -06:00			`// Copyright 2012 The Go Authors. All rights reserved.`
			`// Use of this source code is governed by a BSD-style`
			`// license that can be found in the LICENSE file.`

			`package cgotest`

			`import "testing"`

cmd/go: pass --build-id=none when generating a cgo .o Some systems, like Ubuntu, pass --build-id when linking. The effect is to put a note in the output file. This is not useful when generating an object file with the -r option, as it eventually causes multiple build ID notes in the final executable, all but one of which are for tiny portions of the file and are therefore useless. Disable that by passing an explicit --build-id=none when linking with -r on systems that might do this. LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/119460043 2014-08-07 13:38:39 -06:00			`func TestSetgid(t *testing.T) { testSetgid(t) }`
			`func Test6997(t *testing.T) { test6997(t) }`
			`func TestBuildID(t *testing.T) { testBuildID(t) }`
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			`func Test9400(t *testing.T) { test9400(t) }`