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/1887Reviewed-by: Ian Lance Taylor <iant@golang.org>

Currently when we get a CGI or FCGI request, the remote port of the client
is hard coded to zero, despite nearly every webserver passing down the
REMOTE_PORT variable.

This was likely originally excluded because the CGI RFC (rfc3875) does not
mention anything about the remote port of the client. However every webserver
tested does pass REMOTE_PORT down. This includes Apache 2.2, Apache 2.4,
nginx and lighttpd.

Fixes #8351

Change-Id: I4c6366cb39f0ccc05e038bd31d85f93b76e8d0c8
Reviewed-on: https://go-review.googlesource.com/1750Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Broken by e7173dfd

Fix by simply disabling the relevant tests.

* bug248 and bug345 require errchk, but we can't
  rely on perl being available.
* bug369 is disabled anyway.

Change-Id: Idf73ebccb066943e3fe17c2f662b37238ec74dfe
Reviewed-on: https://go-review.googlesource.com/2052Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

Calls to goproc/deferproc used to push & pop two extra arguments,
the argument size and the function to call.  Now, we allocate space
for those arguments in the outargs section so we don't have to
modify the SP.

Defers now use the stack pointer (instead of the argument pointer)
to identify which frame they are associated with.

A followon CL might simplify funcspdelta and some of the stack
walking code.

Fixes issue #8641

Change-Id: I835ec2f42f0392c5dec7cb0fe6bba6f2aed1dad8
Reviewed-on: https://go-review.googlesource.com/1601Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I8670540a2a9647efbd8b072a54272a04c530e54b
Reviewed-on: https://go-review.googlesource.com/2001Reviewed-by: Minux Ma <minux@golang.org>

OpenBSD 5.5 changed its kernel ABI and OpenBSD 5.6 enabled it.
This CL works on both 5.5 and 5.6.

Fixes #9102.

Change-Id: I4a295be9ab8acbc99e550d8cb7e8f8dacf3a03c5
Reviewed-on: https://go-review.googlesource.com/1932Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: Ieb305b2a4d4ef28d70a8b8ece703f495c5af0529
Reviewed-on: https://go-review.googlesource.com/2051Reviewed-by: Keith Randall <khr@golang.org>

Gccgo creates a struct to hold the arguments for the deferred
function.  In this example the struct holds a type defined in a
different package.  The bug was that gccgo tried to create an equality
function for this struct, and it implemented that function by calling
the equality function for the type defined in the other package.
Since that type is not exported, the reference to the equality
function failed at link time.  Normally it is impossible for a struct
to directly contain a member that is an unexported type from another
package, but in this specific case it was possible.  Fixed in gccgo
with https://codereview.appspot.com/183500043 .

Change-Id: I8ec3a33631225b9ac2a4ac060cb4d10b4635e60b
Reviewed-on: https://go-review.googlesource.com/1690Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

Previously, this code generated bogus section indexes for dynamic
symbols.  It turns out this didn't matter, since we only emit these
when generating an executable and in an executable it only matters
whether a symbol is defined or undefined, but it leads to perplexing
code full of mysterious constants.

Unfortunately, this happens too early to put in real section indexes,
so just use section index 1 to distinguish the symbol from an
undefined symbol.

Change-Id: I0e514604bf31f21683598ebd3e020b66acf767ef
Reviewed-on: https://go-review.googlesource.com/1720Reviewed-by: Russ Cox <rsc@golang.org>

This will be used by ppc64 to add call stubs to the .text section.
ARM needs a similar pass to generate veneers for arm->thumb
transitions.

Change-Id: Iaee74036e60643a56fab15b564718f359c5910eb
Reviewed-on: https://go-review.googlesource.com/2004Reviewed-by: Russ Cox <rsc@golang.org>

Disabled by default, but invaluable when you need it.

Change-Id: If4a75d11d14f70b6840d339aaec4b940dc406493
Reviewed-on: https://go-review.googlesource.com/2012Reviewed-by: Russ Cox <rsc@golang.org>

* bug248, bug345, bug369, and bug429 were ported from bash commands to run scripts. bug369 remains disabled.
* bug395 is a test for issue 1909, which is still open. It is marked as skip now and will be usable with compile with run.go when issue 1909 is fixed.

Fixes #4139

Updates #1909

Change-Id: Ibb5fbfb5cf72ddc285829245318eeacd3fb5a636
Reviewed-on: https://go-review.googlesource.com/1774Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: Ie5a36dbcd809fc165f4198d47641d5a95878460c
Reviewed-on: https://go-review.googlesource.com/2000Reviewed-by: Russ Cox <rsc@golang.org>

For arm and powerpc, as well as x86 without aes instructions.
Contains a mixture of ideas from cityhash and xxhash.

Compared to our old fallback on ARM, it's ~no slower on
small objects and up to ~50% faster on large objects.  More
importantly, it is a much better hash function and thus has
less chance of bad behavior.

Fixes #8737

benchmark                         old ns/op     new ns/op     delta
BenchmarkHash5                    173           181           +4.62%
BenchmarkHash16                   252           212           -15.87%
BenchmarkHash64                   575           419           -27.13%
BenchmarkHash1024                 7173          3995          -44.31%
BenchmarkHash65536                516940        313173        -39.42%
BenchmarkHashStringSpeed          300           279           -7.00%
BenchmarkHashBytesSpeed           478           424           -11.30%
BenchmarkHashInt32Speed           217           207           -4.61%
BenchmarkHashInt64Speed           262           231           -11.83%
BenchmarkHashStringArraySpeed     609           631           +3.61%

Change-Id: I0a9335028f32b10ad484966e3019987973afd3eb
Reviewed-on: https://go-review.googlesource.com/1360Reviewed-by: Russ Cox <rsc@golang.org>

Pointers to zero-sized values may end up pointing to the next
object in memory, and possibly off the end of a span.  This
can cause memory leaks and/or confuse the garbage collector.

By putting the overflow pointer at the end of the bucket, we
make sure that pointers to any zero-sized keys or values don't
accidentally point to the next object in memory.

fixes #9384

Change-Id: I5d434df176984cb0210b4d0195dd106d6eb28f73
Reviewed-on: https://go-review.googlesource.com/1869Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I3b81f2e9eb29ee6349d758b68fe7951b34f15a81
Reviewed-on: https://go-review.googlesource.com/1974Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Icba46194bcbfd86b512eef2599242c715ad4e7d3
Reviewed-on: https://go-review.googlesource.com/2041Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Fixes #9409

Change-Id: I2404cd8bf3ebb07f4b6a2b3e1d58ab69b9f1e8d8
Reviewed-on: https://go-review.googlesource.com/2040Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Handles the case where the parent is pid 1 (common in docker
containers).

Attempted and failed to write a test for this.

Fixes #9263.

Change-Id: I5c6036446c99e66259a4fab1660b6a594f875020
Reviewed-on: https://go-review.googlesource.com/1372Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Move the symMerge recursion stopping condition
from the beginning of symMerge to the callers.

This halves the number of calls to symMerge
while running 'go test sort'.

benchmark                   old ns/op      new ns/op      delta
BenchmarkStable1e6          8358117060     7954143849     -4.83%
BenchmarkStable1e4          40116117       38583285       -3.82%
BenchmarkStableInt1K        119150         115182         -3.33%
BenchmarkStableInt64K       9799845        9515475        -2.90%
BenchmarkStableString1K     388901         393516         +1.19%
BenchmarkStable1e2          124917         123618         -1.04%

Change-Id: I7ba2ca277f213b076fe6830e1139edb47ac53800
Reviewed-on: https://go-review.googlesource.com/1820Reviewed-by: Robert Griesemer <gri@golang.org>

intDataSize ignores unsigned integers, forcing reads/writes to miss the fast path.

Fixes #8956

Change-Id: Ie79b565b037db3c469aa1dc6d0a8a5a9252d5f0a
Reviewed-on: https://go-review.googlesource.com/1777Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I15269722ca3d2654a9dd7a3f8a89ad375dc9bee0
Reviewed-on: https://go-review.googlesource.com/1759Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #9407

Change-Id: I765e8009c7ee22473ac8c2d81c7f6c8ec9866c51
Reviewed-on: https://go-review.googlesource.com/1980Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Change-Id: Iea08b8f4e74a8cd4b4d317273046457c8db956a1
Reviewed-on: https://go-review.googlesource.com/1640Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

This was a copy-paste error from 9l.  Besides incorrectly referring to
cnames9, 6l doesn't even use a->class, so simply remove this.

Fixes #9320

Change-Id: I0e3440c9dae1c3408eb795b3645f9f1dd8f50aed
Reviewed-on: https://go-review.googlesource.com/1516Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #9418

Change-Id: I044fa1d26d972f012f00388a84c4d0f143cf4f63
Reviewed-on: https://go-review.googlesource.com/1970Reviewed-by: Robert Griesemer <gri@golang.org>

Change-Id: I04d2e83f86f021464190f0b0fe0e450cb4662ad9
Reviewed-on: https://go-review.googlesource.com/1971Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Some applications use unpadded base64 format, omitting the trailing
'=' padding characters from the standard base64 format, either to
minimize size or (more justifiably) to avoid use of the '=' character.
Unpadded flavors are standard and documented in section 3.2 of RFC 4648.

To support these unpadded flavors, this change adds two predefined
encoding variables, RawStdEncoding and RawURLEncoding, for unpadded
encodings using the standard and URL character set, respectively.
The change also adds a function WithPadding() to customize the padding
character or disable padding in a custom Encoding.

Finally, I noticed that the existing base64 test-suite was only
exercising the StdEncoding, and not referencing URLEncoding at all.
This change adds test-suite functionality to exercise all four encodings
(the two existing ones and the two new unpadded flavors),
although it still doesn't run *every* test on all four encodings.

Naming: I used the "Raw" prefix because it's more concise than "Unpadded"
and seemed just as expressive, but I have no strong preferences here.
Another short alternative prefix would be "Min" ("minimal" encoding).

Change-Id: Ic0423e02589b39a6b2bb7d0763bd073fd244f469
Reviewed-on: https://go-review.googlesource.com/1511Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Couldn't handle a hex string terminated by anything
other than spaces. Easy to fix.

Fixes #9124.

Change-Id: I18f89a0bd99a105c9110e1ede641873bf9daf3af
Reviewed-on: https://go-review.googlesource.com/1538Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #9188

Change-Id: Ifbf5d9fa78a4f4ceb7f92d42494fe37fa7878c45
Reviewed-on: https://go-review.googlesource.com/1930Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Check for Set error when a boolean flag isn't explicitly given a value.

Fixes #9345

Change-Id: I97a1289f8cf27567d1a726ebe5ef167c800f357c
Reviewed-on: https://go-review.googlesource.com/1897Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

benchmark           old MB/s     new MB/s     speedup
BenchmarkEncode     243.20       279.89       1.15x

benchmark           old allocs     new allocs     delta
BenchmarkEncode     1370           4              -99.71%

Change-Id: I3920bcc04b6dd89efa5da89db5594d4434426d74
Reviewed-on: https://go-review.googlesource.com/1924Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Make golint a bit happier

Change-Id: I8a14342f3e492e92bf5efa611f9ef91176624031
Reviewed-on: https://go-review.googlesource.com/1891Reviewed-by: Minux Ma <minux@golang.org>

Given a file of size N, a request for "Range: bytes=N-*" should
return a 416 [1].  Currently, it returns a 206 and a body of 0
bytes, with the illegal Content-Range of "bytes N-(N-1)/N" [2].

[1]: RFC 7233, sec 2.1: "If a valid byte-range-set includes at least one
byte-range-spec with a first-byte-pos that is less than the current
length of the representation, [...]".  sec 3.1: "If all of the
preconditions are true, the server supports the Range header field for
the target resource, and the specified range(s) are invalid or
unsatisfiable, the server SHOULD send a 416 (Range Not Satisfiable)
response."

[2]: RFC 7233, sec 4.2: "A Content-Range field value is invalid if it
contains a byte-range-resp that has a last-byte-pos value less than its
first-byte-pos value, [...]"

Fixes #8988

Change-Id: If3e1134e7815f5d361efea01873b29aafe3de817
Reviewed-on: https://go-review.googlesource.com/1862Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

with uintptr, the check for < 0 will never succeed in mem_plan9.go's
sbrk() because the brk_ syscall returns -1 on failure. fixes the plan9/amd64 build.

this failed on plan9/amd64 because of the attempt to allocate 136GB in mallocinit(),
which failed. it was just by chance that on plan9/386 allocations never failed.

Change-Id: Ia3059cf5eb752e20d9e60c9619e591b80e8fb03c
Reviewed-on: https://go-review.googlesource.com/1590Reviewed-by: Anthony Martin <ality@pbrane.org>
Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>

Fixes #9177

Change-Id: I1c7e57f0f0a9b00fb3ddc7fa4844ac53ea6df46f
Reviewed-on: https://go-review.googlesource.com/1876Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Co-hacking with Dave Cheney.

Fixes #9405

Change-Id: I14fc3b6a47dcdb5e514e93d062b804bb24e89f47
Reviewed-on: https://go-review.googlesource.com/1875Reviewed-by: Dave Cheney <dave@cheney.net>

Gccgo can only get a backtrace for the currently running thread, which
means that it can only get a backtrace for goroutines currently running
Go code.  When a goroutine is running C code, gccgo has no way to stop
it and get the backtrace.  This test is all about getting a backtrace
of goroutines running C code, so it can't work for gccgo.

Change-Id: I2dff4403841fb544da7396562ab1193875fc14c3
Reviewed-on: https://go-review.googlesource.com/1904Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: I6be5f610af5c56131a9d887569919372bab1d02c
Reviewed-on: https://go-review.googlesource.com/1903Reviewed-by: Minux Ma <minux@golang.org>

Instead of relying on the asm names declared in the gccgo version of
cgo_export.h, just emit a dummy symbol with the right asm name.  This
is enough to let the _cgo_main link succeed, which is all that matters
here.

Fixes #9294.

Change-Id: I803990705b6b226ed0adf17dc57b58a9f501b213
Reviewed-on: https://go-review.googlesource.com/1901Reviewed-by: Minux Ma <minux@golang.org>