During a crash showing goroutine stacks of all threads
(with GOTRACEBACK=crash), it can be that f == nil.

Only happens on Solaris; not sure why.

Change-Id: Iee2c394a0cf19fa0a24f6befbc70776b9e42d25a
Reviewed-on: https://go-review.googlesource.com/17110Reviewed-by: Austin Clements <austin@google.com>

(TestStackBarrierProfiling is failing on darwin/arm.)

Change-Id: I8006d6222ccafc213821e02105896440079caa37
Reviewed-on: https://go-review.googlesource.com/17091Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Some Android OS installations have very strange permissions on their
/system/etc directory, meaning that Readdir fails. Instead use
/system/framework, which is far more regular.

Change-Id: Iefc140614183cda0f875e0f6ef859f4d4eaad9da
Reviewed-on: https://go-review.googlesource.com/17078Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Update golang/go#9327.

Change-Id: Iab7dad31cf6b9f9347c3f34faebb67ecb38b17fc
Reviewed-on: https://go-review.googlesource.com/16701
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

Change-Id: Ife9e019063473bb0a976cfef4b6e78d951fcb09e
Reviewed-on: https://go-review.googlesource.com/17081
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

The nosplit stack is now much bigger, so we can afford to allocate
libcall on stack.

Fix asmsysvicall6 to not update errno if g == nil.

These two fixes TestCgoCallbackGC on solaris, which used to stuck
in a loop.

Change-Id: Id1b13be992dae9f059aa3d47ffffd37785300933
Reviewed-on: https://go-review.googlesource.com/17076
Run-TryBot: Minux Ma <minux@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

iEEETable violates the Go naming conventions and is inconsistent
with the rest of the package. Use ieeeTable instead.

Change-Id: I04b201aa39759d159de2b0295f43da80488c2263
Reviewed-on: https://go-review.googlesource.com/17068Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Iaa0fb133e5fc2078bfaf59ed721fd07a1a713ab3
Reviewed-on: https://go-review.googlesource.com/17075Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

All the heavy lifting was done by Michael Hudson-Doyle.

Change-Id: I176f15581055078854c2ad9a5807c4dcf0f8d8c5
Reviewed-on: https://go-review.googlesource.com/17074Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Solaris needs to make system calls without a g,
and Solaris uses asmcgocall to make system calls.
I know, I know.

I hope this makes CL 16915, fixing #12277, work on Solaris.

Change-Id: If988dfd37f418b302da9c7096f598e5113ecea87
Reviewed-on: https://go-review.googlesource.com/17072Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Run-TryBot: Russ Cox <rsc@golang.org>

Just add one word to clarify that -n -v -x are not the only build flags supported.

Fixes #13237.

Change-Id: I880472639bf2fc1a0751a83041bc7ddd0c9e55f4
Reviewed-on: https://go-review.googlesource.com/17062Reviewed-by: Andrew Gerrand <adg@golang.org>

Update #12416.

Change-Id: I39eb0d1090c08ef9be9dc38d27abab62672cf664
Reviewed-on: https://go-review.googlesource.com/17064Reviewed-by: Andrew Gerrand <adg@golang.org>

In the past, cgo generated Go code and C code.  The C code was linked
into a shared library.  The Go code was built into an executable that
dynamically linked against that shared library.  C wrappers were
exported from the shared library, and the Go code called them.

It was all a long time ago, but in order to permit C code to call back
into Go, somebody implemented #pragma dynexport (https://golang.org/cl/661043)
to export a Go symbol into the dynamic symbol table.  Then that same
person added code to cgo to recognize //export comments
(https://golang.org/cl/853042).  The //export comments were implemented
by generating C code, to be compiled by GCC, that would refer to C code,
to be compiled by 6c, that would call the Go code.  The GCC code would
go into a shared library.  The code compiled by 6c would be in the Go
executable.  The GCC code needed to refer to the 6c code, so the 6c
function was marked with #pragma dynexport.  The important point here is
that #pragma dynexport was used to expose an internal detail of the
implementation of an exported function, because at the time it was
necessary.

Moving forward to today, cgo no longer generates a shared library and 6c
no longer exists.  It's still true that we have a function compiled by
GCC that refers to a wrapper function now written in Go.  In the normal
case today we are doing an external link, and we use a
//go:cgo_export_static function to make the Go wrapper function visible
to the C code under a known name.

The #pragma dynexport statement has become a //go:cgo_export_dynamic
comment on the Go code.  That comment only takes effect when doing
internal linking.  The comment tells the linker to put the symbol in the
dynamic symbol table.  That still makes sense for the now unusual case
of using internal linking with a shared library.

However, all the changes to this code have carefully preserved the
property that the //go:cgo_export_dynamic comment refers to an internal
detail of the implementation of an exported function.  That was
necessary a long time ago, but no longer makes sense.

This CL changes the code to put the actual C-callable function into the
dynamic symbol table.  I considered dropping the comment entirely, but
it turns out that there is even a test for this, so I preserved it.

Change-Id: I66a7958e366e5974363099bfaa6ba862ca327849
Reviewed-on: https://go-review.googlesource.com/17061
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

Fixes #13320.

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

The lack of this annotation causes Value.SetMapIndex to allocate
when it doesn't need to.

Add comments about why it's safe to do so.

Add a test to make sure we stay allocation-free.

Change-Id: I00826e0d73e317a31bdeae5c7e46bf95b0c6ae6a
Reviewed-on: https://go-review.googlesource.com/17060Reviewed-by: David Chase <drchase@google.com>

It's intended primarily as a torture test for OS X.
Apparently Windows can't take it.

Updates fix for #12327.

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

sysmon runs without a P. This means it can't interact with the garbage
collector, so write barriers not allowed in anything that sysmon does.

Fixes #10600.

Change-Id: I9de1283900dadee4f72e2ebfc8787123e382ae88
Reviewed-on: https://go-review.googlesource.com/17006
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

allocm is a very unusual function: it is specifically designed to
allocate in contexts where m.p is nil by temporarily taking over a P.
Since allocm is used in many contexts where it would make sense to use
nowritebarrierrec, this commit teaches the nowritebarrierrec analysis
to stop at allocm.

Updates #10600.

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

This replaces *memHdr with memHdrPtr.

Updates #10600.

Change-Id: I673aa2cd20f29abec8ab91ed7e783718c8479ce1
Reviewed-on: https://go-review.googlesource.com/17009
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David du Colombier <0intro@gmail.com>

This replaces *traceAllocBlock with traceAllocBlockPtr.

Updates #10600.

Change-Id: I94a20d90f04cca7c457b29062427748e315e4857
Reviewed-on: https://go-review.googlesource.com/17004
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

gentraceback is used in many contexts where write barriers are
disallowed. This currently works because the only write barrier is in
assigning frame.argmap in setArgInfo and in practice frame is always
on the stack, so this write barrier is a no-op.

However, we can easily eliminate this write barrier, which will let us
statically disallow write barriers (using go:nowritebarrierrec
annotations) in many more situations. As a bonus, this makes the code
a little more idiomatic.

Updates #10600.

Change-Id: I45ba5cece83697ff79f8537ee6e43eadf1c18c6d
Reviewed-on: https://go-review.googlesource.com/17003
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

This is a bit of a belt-and-suspenders fix.
On OS X, we now parse the Mach-O file to find the __text section,
which is arguably the more proper fix. But it's a bit worrisome to
depend on a name like __text not changing, so we also read more
of the initial file (now 32 kB, up from 8 kB) and scan that too.

Fixes #12327.

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

My version of bash doesn't know what 'declare -A' means.

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

There was no documentation produced by "go doc cmd/asm".
Follow the style set by cmd/compile.

Fixes #13148.

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

The assumption is that there are no nested function calls in complex expressions.
For the most part that assumption is true. It wasn't for these calls inserted during walk.
Fix that.

I looked through all the calls to mkcall in walk and these were the only cases
that emitted calls, that could be part of larger expressions (like not delete),
and that were not already handled.

Fixes #12225.

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

Because there are now multiple packages that compose the runtime
we need to distinguish between the case where a runtime package
is being compiled versus the case the "runtime" package is being
compiled. In golang.org/cl/14204 I mistakenly used
  localpkg.Name == "runtime"
to check against the "runtime" package, but doing this would treat
a package with the path "foo.org/bar/runtime" as the runtime package.
The correct check is
  myimportpath == "runtime"
.

Change-Id: If90e95cef768d91206f2df1c06e27be876722e4e
Reviewed-on: https://go-review.googlesource.com/17059
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Update #12416.

Change-Id: Iccbcb12709d1ca9bea87274f44f93cfcebadb070
Reviewed-on: https://go-review.googlesource.com/17048
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

golang.org/cl/16383 broke android/386 because by a sort of confluence of hacks
no TLS relocations were emitted at all when Flag_shared != 0. The hack in
runtime/cgo works as well in a PIE executable as it does with a position
dependent one, so the simplest fix is to still emit a R_TLS_LE reloc when goos
== "android".

A real fix is to use something more like the IE model code but loading the
offset from %gs to the thread local storage from a global variable rather than
from a location chosen by the system linker (this is how android/arm works).

Issue #9327.

Change-Id: I9fbfc890ec7fe191f80a595b6cf8e2a1fcbe3034
Reviewed-on: https://go-review.googlesource.com/17049Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>

This adds a test that runs CPU profiling with a high load of stack
barriers and stack barrier insertion/removal operations and checks
that both 1) the runtime doesn't crash and 2) stackBarrier itself
never appears in a profile. Prior to the fix for gentraceback starting
in the middle of stackBarrier, condition 2 often failed.

Change-Id: Ic28860448859029779844c4bf3bb28ca84611e2c
Reviewed-on: https://go-review.googlesource.com/17037Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

A sigprof during stack barrier insertion or removal can crash if it
detects an inconsistency between the stkbar array and the stack
itself. Currently we protect against this when scanning another G's
stack using stackLock, but we don't protect against it when unwinding
stack barriers for a recover or a memmove to the stack.

This commit cleans up and improves the stack locking code. It
abstracts out the lock and unlock operations. It uses the lock
consistently everywhere we perform stack operations, and pushes the
lock/unlock down closer to where the stack barrier operations happen
to make it more obvious what it's protecting. Finally, it modifies
sigprof so that instead of spinning until it acquires the lock, it
simply doesn't perform a traceback if it can't acquire it. This is
necessary to prevent self-deadlock.

Updates #11863, which introduced stackLock to fix some of these
issues, but didn't go far enough.

Updates #12528.

Change-Id: I9d1fa88ae3744d31ba91500c96c6988ce1a3a349
Reviewed-on: https://go-review.googlesource.com/17036Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Currently, if a profiling signal happens in the middle of
stackBarrier, gentraceback may see inconsistencies between stkbar and
the barriers on the stack and it will certainly get the wrong return
PC for stackBarrier. In most cases, the return PC won't be a PC at all
and this will immediately abort the traceback (which is considered
okay for a sigprof), but if it happens to be a valid PC this may sent
gentraceback down a rabbit hole.

Fix this by detecting when the gentraceback starts in stackBarrier and
simulating the completion of the barrier to get the correct initial
frame.

Change-Id: Ib11f705ac9194925f63fe5dfbfc84013a38333e6
Reviewed-on: https://go-review.googlesource.com/17035Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This CL adds skipped failing tests, showing differences between HTTP/1
and HTTP/2 behavior. They'll be fixed in later commits.

Only a tiny fraction of the net/http tests have been split into their
"_h1" and "_h2" variants. That will also continue. (help welcome)

Updates #6891
Updates #13315
Updates #13316
Updates #13317

Change-Id: I16c3c381dbe267a3098fb266ab0d804c36473a64
Reviewed-on: https://go-review.googlesource.com/17046
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fix regression from https://golang.org/cl/16829 ("require valid methods
in NewRequest and Transport.RoundTrip").

An empty string is a valid method (it means "GET", per the docs).

Fixes #13311

Change-Id: I26b71dc4ccc146498b5d7e38fbe31ed11dd5a6cf
Reviewed-on: https://go-review.googlesource.com/16952
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

Change-Id: I22d40248e83fcad5ab73c0d402183d06e91064c7
Reviewed-on: https://go-review.googlesource.com/16388Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

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

For #13243.

Change-Id: I802cef3dad5d1236e70d0cd52047008a6a7a311a
Reviewed-on: https://go-review.googlesource.com/17045Reviewed-by: Chris Manghane <cmang@golang.org>

For #13243.

Change-Id: I544a8c44971fad126103157575e983ab528309bf
Reviewed-on: https://go-review.googlesource.com/17044Reviewed-by: Chris Manghane <cmang@golang.org>

Change-Id: Ie24d56422ae2196198a6c306716fa867c1442d6e
Reviewed-on: https://go-review.googlesource.com/17043Reviewed-by: Chris Manghane <cmang@golang.org>

Handling of &(T{}) assumed that the parser would not introduce ()'s.

Also: Better comments around handling of OPAREN syntax tree optimization.

Fixes #13261.

Change-Id: Ifc5047a0448f5e7d74cd42f6608b87dcc9c2f2fb
Reviewed-on: https://go-review.googlesource.com/17040Reviewed-by: Chris Manghane <cmang@golang.org>

Also:
- better error messages in some cases
- factored out function to produce syntax error at given line number

Fixes #13273.

Change-Id: I0192a94731cc23444680a26bd0656ef663e6da0b
Reviewed-on: https://go-review.googlesource.com/16992Reviewed-by: Chris Manghane <cmang@golang.org>