The freebsd-386 and freebsd-amd64 builders are timing out sometimes.
This will give them some more breathing room.
Change-Id: Ib65bd172cca046a52861759a4232d7b4b6514fa8
Reviewed-on: https://go-review.googlesource.com/1994
Reviewed-by: Ian Lance Taylor <iant@golang.org>
malloc checks kindNoPointers and if it is not set and the object
is one pointer in size, it assumes it contains a pointer. So we
must set kindNoPointers correctly; it isn't just a hint.
Fixes#9425
Change-Id: Ia43da23cc3298d6e3d6dbdf66d32e9678f0aedcf
Reviewed-on: https://go-review.googlesource.com/2055
Reviewed-by: Russ Cox <rsc@golang.org>
Replace with uses of //go:linkname in Go files, direct use of name in .s files.
The only one that really truly needs a jump is reflect.call; the jump is now
next to the runtime.reflectcall assembly implementations.
Change-Id: Ie7ff3020a8f60a8e4c8645fe236e7883a3f23f46
Reviewed-on: https://go-review.googlesource.com/1962
Reviewed-by: Austin Clements <austin@google.com>
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>
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/1750
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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/1601
Reviewed-by: Russ Cox <rsc@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/1932
Reviewed-by: Ian Lance Taylor <iant@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/1720
Reviewed-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/2004
Reviewed-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/2012
Reviewed-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/1360
Reviewed-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/1869
Reviewed-by: Russ Cox <rsc@golang.org>
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/1372
Reviewed-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/1820
Reviewed-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/1777
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/1516
Reviewed-by: Russ Cox <rsc@golang.org>
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/1511
Reviewed-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/1538
Reviewed-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/1897
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Make golint a bit happier
Change-Id: I8a14342f3e492e92bf5efa611f9ef91176624031
Reviewed-on: https://go-review.googlesource.com/1891
Reviewed-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/1862
Reviewed-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/1590
Reviewed-by: Anthony Martin <ality@pbrane.org>
Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Co-hacking with Dave Cheney.
Fixes#9405
Change-Id: I14fc3b6a47dcdb5e514e93d062b804bb24e89f47
Reviewed-on: https://go-review.googlesource.com/1875
Reviewed-by: Dave Cheney <dave@cheney.net>
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/1901
Reviewed-by: Minux Ma <minux@golang.org>
This was brought to my attention because a user thought that because
the file was named "example.go" it served as an example of good coding
practice. It's not an example, of course, but may as well use a more
idiomatic style anyhow.
Change-Id: I7aa720f603f09f7d597fb7536dbf46ef09144e28
Reviewed-on: https://go-review.googlesource.com/1902
Reviewed-by: Minux Ma <minux@golang.org>
"x*41" computes the same value as "x*31 + x*7 + x*3" and (when
compiled by gc) requires just one multiply instruction instead of
three.
Alternatively, the expression could be written as "(x<<2+x)<<3 + x" to
use shifts instead of multiplies (which is how GCC optimizes "x*41").
But gc currently emits suboptimal instructions for this expression
anyway (e.g., separate SHL+ADD instructions rather than LEA on
386/amd64). Also, if such an optimization was worthwhile, it would
seem better to implement it as part of gc's strength reduction logic.
Change-Id: I7156b793229d723bbc9a52aa9ed6111291335277
Reviewed-on: https://go-review.googlesource.com/1830
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Previously, liblink would silently truncate register offset constants
to 32 bits. For example,
MOVD $0x200000004(R2),R3
would assemble to
addis r31,r2,0
addi r3,r31,4
To fix this, limit C_LACON to 32 bit (signed) offsets and introduce a
new C_DACON operand type for larger register offsets. We don't
implement this currently, but at least liblink will now give an error
if it encounters an address like this.
Change-Id: I8e87def8cc4cc5b75498b0fb543ac7666cf2964e
Reviewed-on: https://go-review.googlesource.com/1758
Reviewed-by: Minux Ma <minux@golang.org>
On ppc64, there are three ELF ABI versions an ELF file can request.
Previously, we used 0, which means "unspecified". On our test
machines, this meant to use the default (v1 for big endian and v2 for
little endian), but apparently some systems can pick the wrong ABI if
neither is requested. Leaving this as 0 also confuses libbfd, which
confuses gdb, objdump, etc.
Fix these problems by specifying ABI v1 for big endian and v2 for
little endian.
Change-Id: I4d3d5478f37f11baab3681a07daff3da55802322
Reviewed-on: https://go-review.googlesource.com/1800
Reviewed-by: Minux Ma <minux@golang.org>
When we do y = &x for global variables x and y, y gets initialized
at link time. Do the same for y = &x.f if x is a struct and y=&x[5]
if x is an array.
fixes#9217fixes#9355
Change-Id: Iea3c0ce2ce1b309e2b760e345608fd95460b5713
Reviewed-on: https://go-review.googlesource.com/1691
Reviewed-by: Minux Ma <minux@golang.org>
SSLv3 (the old minimum) is still supported and can be enabled via the
tls.Config, but this change increases the default minimum version to TLS
1.0. This is now common practice in light of the POODLE[1] attack
against SSLv3's CBC padding format.
[1] https://www.imperialviolet.org/2014/10/14/poodle.htmlFixes#9364.
Change-Id: Ibae6666ee038ceee0cb18c339c393155928c6510
Reviewed-on: https://go-review.googlesource.com/1791
Reviewed-by: Minux Ma <minux@golang.org>
Fix TLS_FALLBACK_SCSV check when comparing the client version to the
default max version. This enables the TLS_FALLBACK_SCSV check by default
in servers that do not explicitly set a max version in the tls config.
Change-Id: I5a51f9da6d71b79bc6c2ba45032be51d0f704b5e
Reviewed-on: https://go-review.googlesource.com/1776
Reviewed-by: Adam Langley <agl@golang.org>
Fix style by removing unnecessary named result parameter.
Fix doc comment while here.
Change-Id: If8394e696ab37e00a95484d5137955aa06c59520
Reviewed-on: https://go-review.googlesource.com/1781
Reviewed-by: Yasuhiro MATSUMOTO <mattn.jp@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On ppc64, liblink rewrites MOVD's of >32-bit constants by putting the
constant in memory and rewriting the MOVD to load from that memory
address. However, there were two bugs in the condition:
a) owing to an incorrect sign extension, it triggered for all negative
constants, and
b) it could trigger for constant offsets from registers (addresses of
the form $n(Rm) in assembly)
Together, these meant instructions of the form MOVD $-n(Rm), x were
compiled by putting -n in memory and rewriting the MOVD to load this
constant from memory (completely dropping Rm).
Change-Id: I1f6cc980efa3e3d6f164b46c985b2c3b55971cca
Reviewed-on: https://go-review.googlesource.com/1752
Reviewed-by: Minux Ma <minux@golang.org>
People are probably not making this mistake anymore.
Fixes#9164
Change-Id: I86b440ed63d09b4ca676bba7034838860f1a5d8b
Reviewed-on: https://go-review.googlesource.com/1782
Reviewed-by: Minux Ma <minux@golang.org>
It shouldn't semacquire() inside an acquirem(), the runtime
thinks that means deadlock. It actually isn't a deadlock, but it
looks like it because acquirem() does m.locks++.
Candidate for inclusion in 1.4.1. runtime.Stack with all=true
is pretty unuseable in GOMAXPROCS>1 environment.
fixes#9321
Change-Id: Iac6b664217d24763b9878c20e49229a1ecffc805
Reviewed-on: https://go-review.googlesource.com/1600
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
I broke the build in https://golang.org/change/207950a when I made
http.Transport send "Connection: close" request headers when
DisableKeepAlives was set true because I didn't run all the tests
before submitting.
httputil.DumpRequestOut used Transport to get its output, and used it
with DisableKeepAlives, so this changed the output.
Rather than updating golden data in our tests (because surely others
depend on the exact bytes from these in their tests), switch to not
using DisableKeepAlives in DumpRequestOut instead, so the output is
the same as before.
Change-Id: I9fad190be8032e55872e6947802055a6d65244df
Reviewed-on: https://go-review.googlesource.com/1632
Reviewed-by: Andrew Gerrand <adg@golang.org>
No bug was open, but I found an old email to myself to investigate
when I suspected this was happening.
Change-Id: Icedefec6f15a000eaabb2693b0640b3b6c8bf82c
Reviewed-on: https://go-review.googlesource.com/1578
Reviewed-by: Andrew Gerrand <adg@golang.org>
Actually fixing this "bug" would be weird, since io.LimitReader already
does what we need, as demonstrated by net/http's use.
Thanks to @davidfstr for pointing this out.
Change-Id: If707bcc698d1666a369b39ddfa9770685fbe3879
Reviewed-on: https://go-review.googlesource.com/1579
Reviewed-by: Rob Pike <r@golang.org>
Most types are reflexive (k == k for all k of type t), so don't
bother calling equal(k, k) when the key type is reflexive.
Change-Id: Ia716b4198b8b298687843b94b878dbc5e8fc2c65
Reviewed-on: https://go-review.googlesource.com/1480
Reviewed-by: Russ Cox <rsc@golang.org>
Remove carriage returns from //go:generate lines.
Carriage returns are the predecessor of BOMs and still
live on Windows.
Fixes#9264
Change-Id: I637748c74335c696b3630f52f2100061153fcdb4
Reviewed-on: https://go-review.googlesource.com/1564
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
People keep pasting all.bash output into GitHub bugs, which turns
the # lines into <h1> headlines. Add some more #s so that the
bug reports are more readable. Not ideal but seems like the best
of a few bad options.
Change-Id: I4c69930ec304b2d504d7cd66221281a8577b87ae
Reviewed-on: https://go-review.googlesource.com/1286
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
//go:nowritebarrier can only be used in package runtime.
It does not disable write barriers; it is an assertion, checked
by the compiler, that the following function needs no write
barriers.
Change-Id: Id7978b779b66dc1feea39ee6bda9fd4d80280b7c
Reviewed-on: https://go-review.googlesource.com/1224
Reviewed-by: Rick Hudson <rlh@golang.org>
Still using the ancient go/types API. Updating that to the modern API
should be a separate effort in a separate change.
Change-Id: Ic1c5ae3c13711d34fe757507ecfc00ee883810bf
Reviewed-on: https://go-review.googlesource.com/1404
Reviewed-by: David Symonds <dsymonds@golang.org>
We forgot to do the usual API review.
Make that not possible in the future.
I'll pull this change over to the main
branch too, but it's more important
(and only testable) here.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/185050043
I read through and vetted these but others should look too.
LGTM=bradfitz, adg
R=r, minux, bradfitz, adg
CC=adg, golang-codereviews, gri, iant
https://golang.org/cl/182560043
This flag no longer exists. It has been replaced with -unit=byte.
Change-Id: Iff9fc501f2c666067c9b1948c4623c8e3adddb8d
Reviewed-on: https://go-review.googlesource.com/1287
Reviewed-by: Russ Cox <rsc@golang.org>
I tried to submit this in Go 1.4 as cl/107540044 but tripped over the
changes for getting C off the G stack. This is a rewritten version that
avoids cgo and works directly with the underlying log device.
Change-Id: I14c227dbb4202690c2c67c5a613d6c6689a6662a
Reviewed-on: https://go-review.googlesource.com/1285
Reviewed-by: Keith Randall <khr@golang.org>
It could only handle one finalizer before it raised an out-of-bounds error.
Fixes issue #9172
Change-Id: Ibb4d0c8aff2d78a1396e248c7129a631176ab427
Reviewed-on: https://go-review.googlesource.com/1201
Reviewed-by: Russ Cox <rsc@golang.org>
needm used to print an error before exiting when it was called too
early, but this error was lost in the transition to Go. Bring back
the error so we don't silently exit(1) when this happens.
Change-Id: I8086932783fd29a337d7dea31b9d6facb64cb5c1
Reviewed-on: https://go-review.googlesource.com/1226
Reviewed-by: Russ Cox <rsc@golang.org>
Avoids a potential O(n^2) performance problem when dequeueing
from very popular channels.
benchmark old ns/op new ns/op delta
BenchmarkChanPopular 2563782 627201 -75.54%
Change-Id: I231aaeafea0ecd93d27b268a0b2128530df3ddd6
Reviewed-on: https://go-review.googlesource.com/1200
Reviewed-by: Russ Cox <rsc@golang.org>
If the symbol table isn't sorted, we print it and abort. However, we
were missing the line break after each symbol, resulting in one
gigantic line instead of a nicely formatted table.
Change-Id: Ie5c6f3c256d0e648277cb3db4496512a79d266dd
Reviewed-on: https://go-review.googlesource.com/1182
Reviewed-by: Russ Cox <rsc@golang.org>
It is unused. It was introduced in the CL that added InputOffset.
I suspect it was an editing mistake.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/182580043
When we start work on Gerrit, ppc64 and garbage collection
work will continue in the master branch, not the dev branches.
(We may still use dev branches for other things later, but
these are ready to be merged, and doing it now, before moving
to Git means we don't have to have dev branches working
in the Gerrit workflow on day one.)
TBR=rlh
CC=golang-codereviews
https://golang.org/cl/183140043