Internal linking on an ELF system creates two reloc sections, which
must be adjacent. The default is to base section alignment on the
section size, but doing that for ELF reloc sections can introduce a
gap. Set the reloc section alignment explicitly to avoid that.
Fixes#18044.
Change-Id: I8ccc131e60937d30c5f715a34c7803258833fc2f
Reviewed-on: https://go-review.googlesource.com/33872
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
And link it.
Change-Id: Ic0105468435299fb1638f86522f4f3ce417ec1c2
Reviewed-on: https://go-review.googlesource.com/33871
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reversion CL was 33770.
Change-Id: I119f26796bb2b66d302e132dd118847ac3bd6633
Reviewed-on: https://go-review.googlesource.com/33807
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The introduction of NoBody and related body-peeking bug fixes also
added a "cleanup" of sorts to make NewRequest set the returned
Requests's ContentLength to -1 when it didn't know it.
Using -1 to mean unknown is what the documentation says, but then
people apparently(?) depended on it being zero so they could do this:
req, _ := http.NewRequest("POST", url, someNonNilReaderWithUnkownSize)
req.Body = nil
res, err := http.DefaultClient.Do(req)
... and expect it to work.
After https://golang.org/cl/31445 the contrived(?) code above stopped
working, since Body was nil and ContentLength was -1, which has been
disallowed since Go 1.0.
So this restores the old behavior of NewRequest, not setting it to -1.
That part of the fix isn't required as of https://golang.org/cl/31726
(which added NoBody)
I still don't know whether this bug is hypothetical or actually
affected people in practice.
Let's assume it's real for now.
Fixes#18117
Change-Id: I42400856ee92a1a4999b5b4668bef97d885fbb53
Reviewed-on: https://go-review.googlesource.com/33801
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Per recommendation from imgtec.com folk.
Change-Id: I9b6f30572f257acce59842ac55362f52fe36c5ab
Reviewed-on: https://go-review.googlesource.com/33804
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also change a couple of `go get` tests to use MustHaveExternalNetwork
rather than checking testing.Short.
Change-Id: I98ccc05b8b0354f1b7486e28dac5f8341c342a07
Reviewed-on: https://go-review.googlesource.com/33802
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This file is entirely about the implementation of LineHist, and I can
never remember which generic filename in cmd/internal/obj has it.
Rename to line.go to match the already existing line_test.go.
Change-Id: Id01f3339dc550c9759569d5610d808b17bca44d0
Reviewed-on: https://go-review.googlesource.com/33803
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This was a regression from 1.7. See the issue for details.
Fixes#18149.
Change-Id: Ic8f5a35d14edf9254b1275400316cff7aff32a27
Reviewed-on: https://go-review.googlesource.com/33799
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
NoBody is new in Go 1.8.
Found while investigating #18117
Change-Id: I6bda030f358e2270f090d108cb3a89c8a2665fcb
Reviewed-on: https://go-review.googlesource.com/33714
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
func f() {
g()
}
We mistakenly don't add a frame pointer for f. This means f
isn't seen when walking the frame pointer linked list. That
matters for kernel-gathered profiles, and is an impediment for
issues like #16638.
To fix, allocate a stack frame even for otherwise frameless functions
like f. It is a bit tricky because we need to avoid some runtime
internals that really, really don't want one.
No test at the moment, as only kernel CPU profiles would catch it.
Tests will come with the implementation of #16638.
Fixes#18103
Change-Id: I411206cc9de4c8fdd265bee2e4fa61d161ad1847
Reviewed-on: https://go-review.googlesource.com/33754
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Darwin separately stores bits indicating whether a root certificate
should be trusted; this changes Go to read and use those when
initializing SystemCertPool.
Unfortunately, the trust API is very slow. To avoid a delay of up to
0.5s in initializing the system cert pool, we assume that
the trust settings found in kSecTrustSettingsDomainSystem will always
indicate trust. (That is, all root certs Apple distributes are trusted.)
This is not guaranteed by the API but is true in practice.
In the non-cgo codepath, we do not have that benefit, so we must check
the trust status of every certificate. This causes about 0.5s of delay
in initializing the SystemCertPool.
On OS X 10.11 and older, the "security" command requires a certificate
to be provided in a file and not on stdin, so the non-cgo codepath
creates temporary files for each certificate, further slowing initialization.
Updates #18141.
Change-Id: If681c514047afe5e1a68de6c9d40ceabbce54755
Reviewed-on: https://go-review.googlesource.com/33721
Run-TryBot: Quentin Smith <quentin@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Now the net tests pass with -gcflags '-l=4'.
Fixes#18125.
Change-Id: I4e3a46eb0cb3a93b203e74f5bc99c5822331f535
Reviewed-on: https://go-review.googlesource.com/33722
Reviewed-by: Keith Randall <khr@golang.org>
... so we don't have to export gosym.PCValue.
Change-Id: Ie8f196d5e5ab63e3e69d1d7b4bfbbf32b7b5e4f5
Reviewed-on: https://go-review.googlesource.com/33791
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reverts https://golang.org/cl/23672 and tweaks the text to clarify
HTTP/2 request cancelations also cancel the context (not just closing
the TCP conn).
Fixes#18143
Change-Id: I9f838e09b906d455c98f676e5bc5559f8f7ecb17
Reviewed-on: https://go-review.googlesource.com/33769
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Require parameter names to not begin with a symbol.
Change-Id: I5dfe9d4e181f0daf71dad2f395aca41c68678cbe
Reviewed-on: https://go-review.googlesource.com/33493
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Commit 303b69fe packed bitvectors more tightly, but missed a comment
describing their old layout. Update that comment.
Change-Id: I095ccb01f245197054252545f37b40605a550dec
Reviewed-on: https://go-review.googlesource.com/33718
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
And reflow paragraph while I'm at it.
Change-Id: Ia13bb364783790fbd9f8b69ef268f8a4b71679cb
Reviewed-on: https://go-review.googlesource.com/33767
Reviewed-by: Chris Broadfoot <cbro@golang.org>
This reverts commit d24b57a6a1.
Reason for revert: Further complications arised (issue 18100). We'll try again in Go 1.9.
Change-Id: I5ca93d2643a4be877dd9c2d8df3359718440f02f
Reviewed-on: https://go-review.googlesource.com/33770
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
so that our release note can reference a simple command to check if
the processor implements ARMv6K or not.
Updates #17082.
Change-Id: I9ca52051e5517394a7cd6b778fb822c3ee435f84
Reviewed-on: https://go-review.googlesource.com/33686
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This fixes a bug in -l=3 or higher.
To inline a variadic function, the compiler generates code that constructs
a slice of arguments for the variadic parameter. Consider the function
func Foo(xs ...string)
and the call Foo("hello", "world"). To inline the call to Foo, the
compiler used to generate
xs := [2]string{"hello", "world"}[:]
which doesn't type check:
invalid operation [2]string literal[:] (slice of unaddressable value).
Now, the compiler generates
xs := []string{"hello", "world"}
which does type check.
Fixes#18116.
Change-Id: I0ee531ef2e6cc276db6fb12602b25a46d6d5db21
Reviewed-on: https://go-review.googlesource.com/33671
Reviewed-by: Keith Randall <khr@golang.org>
Rather then using a sleep in the fake DB, go to a channel
select and wait for the context to be done.
Fixes#18115
Change-Id: I6bc3a29db58c568d0a7ea06c2a354c18c9e798b2
Reviewed-on: https://go-review.googlesource.com/33712
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
From the garbage collector's perspective, time can move backwards in
cgocall. However, in the midst of this time warp, the pointer
arguments to cgocall can go from dead back to live. If a stack growth
happens while they're dead and then a GC happens when they become live
again, GC can crash with a bad heap pointer.
Specifically, the sequence that leads to a panic is:
1. cgocall calls entersyscall, which saves the PC and SP of its call
site in cgocall. Call this PC/SP "X". At "X" both pointer arguments
are live.
2. cgocall calls asmcgocall. Call the PC/SP of this call "Y". At "Y"
neither pointer argument is live.
3. asmcgocall calls the C code, which eventually calls back into the
Go code.
4. cgocallbackg remembers the saved PC/SP "X" in some local variables,
calls exitsyscall, and then calls cgocallbackg1.
5. The Go code causes a stack growth. This stack unwind sees PC/SP "Y"
in the cgocall frame. Since the arguments are dead at "Y", they are
not adjusted.
6. The Go code returns to cgocallbackg1, which calls reentersyscall
with the recorded saved PC/SP "X", so "X" gets stashed back into
gp.syscallpc/sp.
7. GC scans the stack. It sees there's a saved syscall PC/SP, so it
starts the traceback at PC/SP "X". At "X" the arguments are considered
live, so it scans them, but since they weren't adjusted, the pointers
are bad, so it panics.
This issue started as of commit ca4089ad, when the compiler stopped
marking arguments as live for the whole function.
Since this is a variable liveness issue, fix it by adding KeepAlive
calls that keep the arguments live across this whole time warp.
The existing issue7978 test has all of the infrastructure for testing
this except that it's currently up to chance whether a stack growth
happens in the callback (it currently only happens on the
linux-amd64-noopt builder, for example). Update this test to force a
stack growth, which causes it to fail reliably without this fix.
Fixes#17785.
Change-Id: If706963819ee7814e6705693247bcb97a6f7adb8
Reviewed-on: https://go-review.googlesource.com/33710
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Be consistent with the argument names already provided. Also
parameter is the variable, argument is the value.
Fixes#18099
Change-Id: Idb3f4e9ffc214036c721ddb4f614ec6c95bb7778
Reviewed-on: https://go-review.googlesource.com/33660
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
