Ran rsc.io/grind rev 6f0e601 on the source files.
The cleanups move var declarations as close to the use
as possible, splitting disjoint uses of the var into separate
variables. They also remove dead code (especially in
func sudoaddable), which helps with the var moving.
There's more cleanup to come, but this alone cuts the
time spent compiling html/template on my 2013 MacBook Pro
from 3.1 seconds to 2.3 seconds.
Change-Id: I4de499f47b1dd47a560c310bbcde6b08d425cfd6
Reviewed-on: https://go-review.googlesource.com/5637
Reviewed-by: Rob Pike <r@golang.org>
Convert using rsc.io/c2go rev a97ff47.
Notable changes:
- %% in format string now correctly preserved
- reintroduce "signal handler" to hide internal faults
after errors have been printed
Change-Id: Ic5a94f1c3a8015a9054e21c8969b52d964a36c45
Reviewed-on: https://go-review.googlesource.com/5633
Reviewed-by: Rob Pike <r@golang.org>
These don't work with the new compiler, because the
new compiler doesn't have the custom syntax errors
that I built for the old compiler. It will, just not yet.
(Issue #9968.)
Change-Id: I658f7dab2c7f855340a501f9ae4479c097b28cd3
Reviewed-on: https://go-review.googlesource.com/5632
Reviewed-by: Rob Pike <r@golang.org>
The routine mallocgc retrieves objects from freelists. Prefetch
the object that will be returned in the next call to mallocgc.
Experiments indicate that this produces a 1% improvement when using
prefetchnta and less when using prefetcht0, prefetcht1, or prefetcht2.
Benchmark numbers indicate a 1% improvement over no
prefetch, much less over prefetcht0, prefetcht1, and prefetcht2.
These numbers were for the garbage benchmark with MAXPROCS=4
no prefetch >> 5.96 / 5.77 / 5.89
prefetcht0(uintptr(v.ptr().next)) >> 5.88 / 6.17 / 5.84
prefetcht1(uintptr(v.ptr().next)) >> 5.88 / 5.89 / 5.91
prefetcht2(uintptr(v.ptr().next)) >> 5.87 / 6.47 / 5.92
prefetchnta(uintptr(v.ptr().next)) >> 5.72 / 5.84 / 5.85
Change-Id: I54e07172081cccb097d5b5ce8789d74daa055ed9
Reviewed-on: https://go-review.googlesource.com/5350
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Austin Clements <austin@google.com>
The code concerning quoted-printable encoding (RFC 2045) and its
variant for MIME headers (RFC 2047) is currently spread in
mime/multipart and net/mail. It is also not exported.
This commit is the second step to fix that issue. It moves the
RFC 2047 encoding and decoding functions from net/mail to
internal/mime. The exported API is unchanged.
Updates #4943
Change-Id: I5f58aa58e74bbe4ec91b2e9b8c81921338053b00
Reviewed-on: https://go-review.googlesource.com/2101
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We currently have only one supported darwin/arm device, a locked iOS
machine. It requires cgo binaries.
Change-Id: If36a152e6a743e4a58ea3470e62cccb742630a5d
Reviewed-on: https://go-review.googlesource.com/5443
Reviewed-by: Russ Cox <rsc@golang.org>
Makes them compatible with the new asm.
Applied mechanically from vet diagnostics.
Manual edits: the names for arguments in time·now(SB) in runtime/sys_*_arm.s.
Change-Id: Ib295390d9509d306afc67714e3f50dc832256625
Reviewed-on: https://go-review.googlesource.com/5576
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This was supposed to be in the previous CL, but I forgot to 'git rw' it down.
Change-Id: Ia5e14ca2c7640f08abbbed1a777a6cf04d71d0e7
Reviewed-on: https://go-review.googlesource.com/5570
Reviewed-by: Russ Cox <rsc@golang.org>
The wildcard 'std' is defined in documentation to be all the packages
in the Go standard library. It has also historically matched commands
in the main repo, but as we implement core commands in Go, that
becomes problematic. We need a wildcard that means just the library,
and since 'std' is already documented to have that definition, make it so.
Add a new wildcard 'cmd' for the commands in the main repo ($GOROOT).
Commands that want both can say 'std cmd' (or 'cmd std') to get the
effect of the old 'std'.
Update make.bash etc to say both std and cmd most of the time.
Exception: in race.bash, do not install race-enabled versions of
the actual commands. This avoids trying to write binaries while
using them, but more importantly it avoids enabling the race
detector and its associated memory overhead for the already
memory-hungry compilers.
Change-Id: I26bb06cb13b636dfbe71a015ee0babeb270a0275
Reviewed-on: https://go-review.googlesource.com/5550
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
With a trivial Golang-built program loaded in gdb-7.8.90.20150214-7.fc23.x86_64
I get this error:
(gdb) source ./src/runtime/runtime-gdb.py
Loading Go Runtime support.
Traceback (most recent call last):
File "./src/runtime/runtime-gdb.py", line 230, in <module>
_rctp_type = gdb.lookup_type("struct reflect.rtype").pointer()
gdb.error: No struct type named reflect.rtype.
(gdb) q
No matter if this struct should or should not be in every Golang-built binary
this change should fix that with no disadvantages.
Change-Id: I0c490d3c9bbe93c65a2183b41bfbdc0c0f405bd1
Reviewed-on: https://go-review.googlesource.com/5521
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reconvert using rsc.io/c2go rev 27b3f59.
(Same as last conversion, but C sources have changed
due to merging master into this branch.)
Change-Id: Ib314bb9ac14a726ceb83e2ecf4d1ad2d0b331c38
Reviewed-on: https://go-review.googlesource.com/5471
Reviewed-by: Rob Pike <r@golang.org>
Representation in printout of MRC instruction differs between
32- and 64-bit machines. It's just a hex dump. Fix this one day,
but for now just comment out the instruction.
Change-Id: I4709390659e2e0f2d18ff6f8e762f97cdbfb4c16
Reviewed-on: https://go-review.googlesource.com/5424
Reviewed-by: Rob Pike <r@golang.org>
Add trivial golden test that verifies output matches expectation.
The input is based on the old grammar and is intended to cover
the space of the input language.
PPC64 and ARM only for now; others to follow.
Change-Id: Ib5957822bcafd5b9d4c1dea1c03cc6ee1238f7ef
Reviewed-on: https://go-review.googlesource.com/5421
Reviewed-by: Russ Cox <rsc@golang.org>
As with the previous round for ppc64, this CL fixes a couple of things
that 5a supported but asm did not, both simple.
1) Allow condition code on MRC instruction; this was marked as a TODO.
2) Allow R(n) notation in ARM register shifts. The code needs a rethink
but the tests we're leading toward will make the rewrite easier to test and
trust.
Change-Id: I5b52ad25d177a74cf07e089dddfeeab21863c424
Reviewed-on: https://go-review.googlesource.com/5422
Reviewed-by: Russ Cox <rsc@golang.org>
Applying my post-submit comments from CL 5120.
The rewrite there changed the code from writing to the stack
frame to writing below the stack frame.
Change-Id: Ie7e0563c0c1731fede2bcefeaf3c9d88a0cf4063
Reviewed-on: https://go-review.googlesource.com/5470
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Trace command allows to visualize and analyze traces.
Run as:
$ go tool trace binary trace.file
The commands opens web browser with the main page,
which contains links for trace visualization,
blocking profiler, network IO profiler and per-goroutine
traces.
Also move trace parser from runtime/pprof/trace_parser_test.go
to internal/trace/parser.go, so that it can be shared between
tests and the command.
Change-Id: Ic97ed59ad6e4c7e1dc9eca5e979701a2b4aed7cf
Reviewed-on: https://go-review.googlesource.com/3601
Reviewed-by: Andrew Gerrand <adg@golang.org>
In most cases we pass return PC to race detector,
and race runtime subtracts one from them.
However, in manual instrumentation in runtime
we pass function start PC to race runtime.
Race runtime can't distinguish these cases
and so it does not subtract one from top PC.
This leads to bogus line numbers in some cases.
Make it consistent and always pass what looks
like a return PC, so that race runtime can
subtract one and still get PC in the same function.
Also delete two unused functions.
Update #8053
Change-Id: I4242dec5e055e460c9a8990eaca1d085ae240ed2
Reviewed-on: https://go-review.googlesource.com/4902
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is a nice split but more importantly it provides a better
way to fit the checkmark phase into the sequencing.
Also factor out common span copying into gcSpanCopy.
Change-Id: Ia058644974e4ed4ac3cf4b017a3446eb2284d053
Reviewed-on: https://go-review.googlesource.com/5333
Reviewed-by: Austin Clements <austin@google.com>
See the following issue for context:
https://github.com/golang/go/issues/9729#issuecomment-74648287
In short, RDTSC can produce skewed results without preceding LFENCE/MFENCE.
Information on this matter is very scrappy in the internet.
But this is what linux kernel does (see rdtsc_barrier).
It also fixes the test program on my machine.
Update #9729
Change-Id: I3c1ffbf129fdfdd388bd5b7911b392b319248e68
Reviewed-on: https://go-review.googlesource.com/5033
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This changes fixes two issues with regard to handling routing messages
as follows:
- Misparsing on platforms (such as FreeBSD) supporting multiple
architectures in the same kernel (kern.supported_archs="amd64 i386")
- Misparsing with unimplemented messages such as route, interface
address state notifications
To fix those issues, this change implements all the required socket
address parsers, adds a processor architecture identifying function to
FreeBSD and tests.
Fixes#9707.
Fixes#8203.
Change-Id: I7ed7b4a0b6f10f54b29edc681a2f35603f2d8d45
Reviewed-on: https://go-review.googlesource.com/4330
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Before Go 1.4, the traditional way to work with a private Github
repository was to run something similar the following:
```
git config --global url."git@github.com:".insteadOf "https://github.com/"
```
It would allow go get and friends to transparently work as expected,
automatically rewriting https URLs to use SSH for auth. This worked both
when pushing and pulling.
In Go 1.4 this broke, now requiring the use of `go get -f` instead of `go get`
in order to fetch private repositories. This seems neither intended nor
practical, as it requires changing a lot of tooling.
So just use `git config remote.origin.url` instead of `git remote -v` as
this reflects the actual substitution intended in the `insteadOf` config
directive.
Also remove now useless parsing.
Also add a check against supported schemes to avoid errors in later
commands using this URL and expecting such a scheme.
Fixes#9697
Change-Id: I907327f83504302288f913a68f8222a5c2d673ee
Reviewed-on: https://go-review.googlesource.com/3504
Reviewed-by: Andrew Gerrand <adg@golang.org>
I created a .s file that covered every instruction and operand production
in 9a/a.y and made sure that 9a and asm give bit-identical results for it.
I found a few things, including one addressing mode (R1+R2) that was
not present in the source we use. Fixed those
I also found quite a few things where 9a's grammar accepts the instruction
but liblink rejects it. These need to be sorted out, and I will do that separately.
Once that's done, I'll turn my test file into a proper test.
Change-Id: Ib093271b0f7ffd64ffed164ed2a820ebf2420e34
Reviewed-on: https://go-review.googlesource.com/5361
Reviewed-by: Russ Cox <rsc@golang.org>
Fix many incorrect FP references and a few other details.
Some errors remain, especially in vlop, but fixing them requires semantics. For another day.
Change-Id: Ib769fb519b465e79fc08d004a51acc5644e8b259
Reviewed-on: https://go-review.googlesource.com/5288
Reviewed-by: Russ Cox <rsc@golang.org>
Reconvert using rsc.io/c2go rev 27b3f59.
Changes to converter:
- fatal does not return, so no fallthrough after fatal in switch
- many more function results and variables identified as bool
- simplification of negated boolean expressions
Change-Id: I3bc67da5e46cb7ee613e230cf7e9533036cc870b
Reviewed-on: https://go-review.googlesource.com/5171
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
c2go was putting a fallthrough after the fatal call.
Changed c2go to know that fatal doesn't return,
but then there is a missing return at the end of
the translated Go function.
Move code around a little to make C and Go agree.
Change-Id: Icef3d55ccdde0709c02dd0c2b78826f6da33a146
Reviewed-on: https://go-review.googlesource.com/5170
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
That is, I accidentally dropped this change of Austin's
when preparing my CL. I blame Git.
Change-Id: I9dd772c84edefad96c4b16785fdd2dea04a4a0d6
Reviewed-on: https://go-review.googlesource.com/5320
Reviewed-by: Austin Clements <austin@google.com>
Move code from malloc1.go, malloc2.go, mem.go, mgc0.go into
appropriate locations.
Factor mgc.go into mgc.go, mgcmark.go, mgcsweep.go, mstats.go.
A lot of this code was in certain files because the right place was in
a C file but it was written in Go, or vice versa. This is one step toward
making things actually well-organized again.
Change-Id: I6741deb88a7cfb1c17ffe0bcca3989e10207968f
Reviewed-on: https://go-review.googlesource.com/5300
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
They use too much memory in the current Go compiler draft.
This should fix some builders.
Reenabling is #9933.
Change-Id: Ib5ef348b2c55d2012ffed765f2a6df99dec171f4
Reviewed-on: https://go-review.googlesource.com/5302
Reviewed-by: Russ Cox <rsc@golang.org>
Until recently, struct workbuf had only lfnode and uintptr fields
before the obj array to make it convenient to compute the size of the
obj array. It slowly grew more fields until this became inconvenient
enough that it was restructured to make the size computation easy.
Now the size computation doesn't care what the field types are, so
switch to more natural types.
Change-Id: I966140ba7ebb4aeb41d5c66d9d2a3bdc17dd4bcf
Reviewed-on: https://go-review.googlesource.com/5262
Reviewed-by: Russ Cox <rsc@golang.org>
This converts the garbage collector from directly manipulating work
buffers to using the new gcWork abstraction.
The previous management of work buffers was rather ad hoc. As a
result, switching to the gcWork abstraction changes many details of
work buffer management.
If greyobject fills a work buffer, it can now pull from work.partial
in addition to work.empty.
Previously, gcDrain started with a partial or empty work buffer and
fetched an empty work buffer if it filled its current buffer (in
greyobject). Now, gcDrain starts with a full work buffer and fetches
an partial or empty work buffer if it fills its current buffer (in
greyobject). The original behavior was bad because gcDrain would
immediately drop the empty work buffer returned by greyobject and
fetch a full work buffer, which greyobject was likely to immediately
overflow, fetching another empty work buffer, etc. The new behavior
isn't great at the start because greyobject is likely to immediately
overflow the full buffer, but the steady-state behavior should be more
stable. Both before and after this change, gcDrain fetches a full
work buffer if it drains its current buffer. Basically all of these
choices are bad; the right answer is to use a dual work buffer scheme.
Previously, shade always fetched a work buffer (though usually from
m.currentwbuf), even if the object was already marked. Now it only
fetches a work buffer if it actually greys an object.
Change-Id: I8b880ed660eb63135236fa5d5678f0c1c041881f
Reviewed-on: https://go-review.googlesource.com/5232
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
This introduces a producer/consumer abstraction for GC work pointers
that internally handles the details of filling, draining, and
shuffling work buffers.
In addition to simplifying the GC code, this should make it easy for
us to change how we use work buffers, including cleaning up how we use
the work.partial queue, reintroducing a FIFO lookahead cache, adding
prefetching, and using dual buffers to avoid flapping.
This commit doesn't change any existing code. The following commit
will switch the garbage collector from explicit workbuf manipulation
to gcWork.
Change-Id: Ifbfe5fff45bf0362d6d7c3cecb061f0c9874077d
Reviewed-on: https://go-review.googlesource.com/5231
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Fairly straightforward. A couple of unusual addressing tricks.
Also added the ability to write R(10) to mean R10. PPC64 uses
this for a couple of large register spaces. It appears for ARM now
as well, since I saw some uses of that before, although I rewrote
them in our source. I could put it in for 386 and amd64 but it's
not worth it.
Change-Id: I3ffd7ffa62d511b95b92c3c75b9f1d621f5393b6
Reviewed-on: https://go-review.googlesource.com/5282
Reviewed-by: Russ Cox <rsc@golang.org>
Oversight in 9a: did not set the static bit in the assembler for
symbols with <>.
Change-Id: Id508dcd3ed07733e60395aefa86d0035faab14a9
Reviewed-on: https://go-review.googlesource.com/5280
Reviewed-by: Russ Cox <rsc@golang.org>
Nit. There's no reason to take a uintptr and doing so just requires
casts in annoying places.
Change-Id: Ifeb9638c6d94eae619c490930cf724cc315680ba
Reviewed-on: https://go-review.googlesource.com/5230
Reviewed-by: Russ Cox <rsc@golang.org>
The comment previously was reversed in sense (it appeared to be
describing unmarshaling). I've fixed that, and added the caveat that map
keys are subject to UTF-8 coercion like other strings.
Change-Id: Id08082aa71401a6e7530a42f979fbb50bd1f4e6a
Reviewed-on: https://go-review.googlesource.com/5221
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
if their nominal Min and Max points differ.
This is a behavior change, but arguably a bug fix, as Eq wasn't
previously consistent with In, and the concept of a rectangle being a
set of points. This is demonstrated by the new geom_test.go test.
It does mean that r.Eq(s) no longer implies that Inset'ting both r and s
with a negative inset results in two rectangles that are still Eq, but
that seems acceptable to me.
The previous behavior is still available as "r == s".
Also clarify the image.Rect doc comment when the inputs are
non-canonical.
Also simplify the Point and Rectangle Eq implementations dating from
before Go 1.0, when you couldn't compare structs via the == operator.
Change-Id: Ic39e628db31dc5fe5220f4b444e6d5000eeace5b
Reviewed-on: https://go-review.googlesource.com/5006
Reviewed-by: Rob Pike <r@golang.org>
Env vars were incorrectly copying whole value of http.RemoteAddr
to REMOTE_ADDR and REMOTE_HOST. They contained IP:port pair which
instead should only have IP (RFC 3875, other sources).
Module also was not setting REMOTE_PORT variable which become de-facto
standard for passing TCP client port to CGI scripts (Apache mod_cgi,
IIS, and probably others)
Fixes#9861
Change-Id: Ia73e664c48539e3c7db4997d09d957884e98d8a5
Reviewed-on: https://go-review.googlesource.com/4933
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In CL 3964, NULL was used instead of nil.
However, Plan 9 doesn't declare NULL.
Change-Id: Ied3850aca5c8bca5974105129a37d575df33f6ec
Reviewed-on: https://go-review.googlesource.com/5150
Reviewed-by: Minux Ma <minux@golang.org>
Fixes#8291
There were several complaints about closure names in the issue tracker.
The first problem is that you see names like net/http.func·001
in profiles, traces, etc. And there is no way to figure out what
is that function.
Another issue is non-US-ascii symbols. All programs out there
should accept UTF-8. But unfortunately it is not true in reality.
For example, less does not render middle dot properly.
This change prepends outer function name to closure name and
replaces middle dot with dot. Now names look like:
main.glob.func1
main.glob.func2
main.glob.func2.1
main.init.1
main.init.1.func1
main.init.1.func1.1
main.main.func1
main.main.func1.1
Change-Id: I725726af88f2ad3ced2e3450f0f06bf459fd91c0
Reviewed-on: https://go-review.googlesource.com/3964
Reviewed-by: Russ Cox <rsc@golang.org>
This will get fixed properly upstream, but this will serve for now.
Change-Id: I25e5210d190bc7a06a5b9f80724e3360d1a6b10c
Reviewed-on: https://go-review.googlesource.com/5121
Reviewed-by: Russ Cox <rsc@golang.org>
Require a name to be specified when referencing the pseudo-stack.
If you want a real stack offset, use the hardware stack pointer (e.g.,
R13 on arm), not SP.
Fix affected assembly files.
Change-Id: If3545f187a43cdda4acc892000038ec25901132a
Reviewed-on: https://go-review.googlesource.com/5120
Run-TryBot: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Historically, yacc has supported various kinds of inspections
and manipulations of the parser state, exposed as global variables.
The Go implementation of yacc puts that state (properly) in local
stack variables, so it can only be exposed explicitly.
There is now an explicit parser type, yyParser, returned by a
constructor, yyNewParser.
type yyParser interface {
Parse(yyLexer) int
Lookahead() int
}
Parse runs a parse. A call to the top-level func Parse
is equivalent to calling yyNewParser().Parse, but constructing
the parser explicitly makes it possible to access additional
parser methods, such as Lookahead.
Lookahead can be called during grammar actions to read
(but not consume) the value of the current lookahead token,
as returned by yylex.Lex. If there is no current lookahead token,
Lookahead returns -1. Invoking Lookahead corresponds to
reading the global variable yychar in a traditional Unix yacc grammar.
To support Lookahead, the internal parsing code now separates
the return value from Lex (yychar) from the reencoding used
by the parsing tables (yytoken). This has the effect that grammars
that read yychar directly in the action (possible since the actions
are in the same function that declares yychar) now correctly see values
from the Lex return value space, not the internal reencoding space.
This can fix bugs in ported grammars not even using SetParse and Lookahead.
(The reencoding was added on Plan 9 for large character sets.
No Plan 9 programs using yacc looked at yychar.)
Other methods may be added to yyParser later as needed.
Obvious candidates include equivalents for the traditional
yyclearin and yyerrok macros.
Change-Id: Iaf7649efcf97e09f44d1f5bc74bb563a11f225de
Reviewed-on: https://go-review.googlesource.com/4850
Reviewed-by: Rob Pike <r@golang.org>
First draft of converted Go compiler, using rsc.io/c2go rev 83d795a.
Change-Id: I29f4c7010de07d2ff1947bbca9865879d83c32c3
Reviewed-on: https://go-review.googlesource.com/4851
Reviewed-by: Rob Pike <r@golang.org>
Set TYPE_BRANCH for x(PC) in the parser and the assembler has less work to do.
This also makes the operand test handle -4(PC) correctly.
Also add a special test case for AX:DX, which should be fixed in obj really.
Change-Id: If195e3a8cf3454a73508633e9b317d66030da826
Reviewed-on: https://go-review.googlesource.com/5071
Reviewed-by: Russ Cox <rsc@golang.org>
Generated by reducing all the amd64 operands in the core.
Will add 386 and ARM later; this is a trial balloon.
NOTE: There is at least one anomaly: AX:DX doesn't print correctly in this situation.
Change-Id: I9f327c1890b100e3edb7b1b2a1c01f3e4b798f43
Reviewed-on: https://go-review.googlesource.com/4967
Reviewed-by: Russ Cox <rsc@golang.org>
Apparently when ARM stops at a GDB breakpoint, it appears to be in
syscall.Syscall. The "info goroutines" test expected it to be in a
runtime function. Since this isn't fundamental to the test, simply
tweak the test's regexp to make sure "info goroutines" prints some
running goroutine with an active M, but don't require it to be in any
particular function.
Change-Id: Iba2618b46d3dc49cef62ffb72484b83ea7b0317d
Reviewed-on: https://go-review.googlesource.com/5060
Reviewed-by: Dave Cheney <dave@cheney.net>
All of the other memory-related source files start with "m". Keep up
the tradition.
Change-Id: Idd88fdbf2a1453374fa12109b949b1c4d149a4f8
Reviewed-on: https://go-review.googlesource.com/4853
Reviewed-by: Minux Ma <minux@golang.org>
Rather than reaching in to slices directly in the slice pretty
printer, use the newly introduced SliceValue wrapper.
Change-Id: Ibb25f8c618c2ffb3fe1a8dd044bb9a6a085df5b7
Reviewed-on: https://go-review.googlesource.com/4936
Reviewed-by: Minux Ma <minux@golang.org>
"info goroutines" is failing because it hasn't kept up with changes in
the 1.5 runtime. This fixes three issues preventing "info goroutines"
from working. allg is no longer a linked list, so switch to using the
allgs slice. The g struct's 'status' field is now called
'atomicstatus', so rename uses of 'status'. Finally, this was trying
to parse str(pc) as an int, but str(pc) can return symbolic
information after the raw hex value; fix this by stripping everything
after the first space.
This also adds a test for "info goroutines" to runtime-gdb_test, which
was previously quite skeletal.
Change-Id: I8ad83ee8640891cdd88ecd28dad31ed9b5833b7a
Reviewed-on: https://go-review.googlesource.com/4935
Reviewed-by: Minux Ma <minux@golang.org>
R15 is the real register. PC is a pseudo-register that we are making
illegal in this context as part of the grand assembly unification.
Change-Id: Ie0ea38ce7ef4d2cf4fcbe23b851a570fd312ce8d
Reviewed-on: https://go-review.googlesource.com/4966
Reviewed-by: Minux Ma <minux@golang.org>
Handle the special name of R10 on the ARM - it's g - when it appears
in a register list [R0, g, R3]. Also simplify the pseudo-register parsing
a little.
Should fix the ARM build.
Change-Id: Ifcafc8195dcd3622653b43663ced6e4a144a3e51
Reviewed-on: https://go-review.googlesource.com/4965
Reviewed-by: Russ Cox <rsc@golang.org>
Mishandled the complex addressing mode in masks<>(SB)(CX*8)
as a casualty of the ARM work. Fix by backing all the flows up to
the state where registerIndirect is always called with the input
sitting on the opening paren.
With this, build passes for me with linux-arm, linux-386, and linux-amd64.
Change-Id: I7cae69a6fa9b635c79efd93850bd1e744b22bc79
Reviewed-on: https://go-review.googlesource.com/4964
Reviewed-by: Russ Cox <rsc@golang.org>
A consequence of the ARM work overlooked that SP is a real register
on x86, so we need to detect it specially.
This will be done better soon, but this is a fast fix for the build.
Change-Id: Ia30d111c3f42a5f0b5f4eddd4cc4d8b10470c14f
Reviewed-on: https://go-review.googlesource.com/4963
Reviewed-by: Russ Cox <rsc@golang.org>
The tools have been fixed to not do this, but verifyAsm depends on this
being fixed.
TBR=rsc
Change-Id: Ia8968cc803b3498dfa2f98188c6ed1cf2e11c66d
Reviewed-on: https://go-review.googlesource.com/4962
Reviewed-by: Rob Pike <r@golang.org>
There are many peculiarites of the ARM architecture that require work:
condition codes, new instructions, new instruction arg counts, and more.
Rewrite the parser to do a cleaner job, flowing left to right through the
sequence of elements of an operand.
Add ARM to arch.
Add ARM-specific details to the arch in a new file, internal/arch/arm.
These are probably better kept away from the "portable" asm. However
there are some pieces, like MRC, that are hard to disentangle. They
can be cleaned up later.
Change-Id: I8c06aedcf61f8a3960a406c094e168182d21b972
Reviewed-on: https://go-review.googlesource.com/4923
Reviewed-by: Russ Cox <rsc@golang.org>
Because text/scanner hides the spaces, the lexer treated
#define A(x)
and
#define A (x)
the same, but they are not: the first is an argument with macros, the
second is a simple one-word macro whose definition contains parentheses.
Fix this by noticing the relative column number as we move from A to (.
Hacky but simple.
Also add a helper to recognize the peculiar ARM shifted register operators.
Change-Id: I2cad22f5f1e11d8dad40ad13955793d178afb3ae
Reviewed-on: https://go-review.googlesource.com/4872
Reviewed-by: Russ Cox <rsc@golang.org>
This just adds test cases. Optimizing CMYK draws will be a follow-up
change.
Change-Id: Ic0d6343d420cd021e21f88623ad7182e93017da9
Reviewed-on: https://go-review.googlesource.com/4941
Reviewed-by: Rob Pike <r@golang.org>
We can use processor architecture or hardware platform as part of
hostname and it leads to misconfiguration of GOHOSARCH.
For example,
$ uname -m -v
FreeBSD 10.1-RELEASE-p5 #0: Tue Jan 27 08:52:50 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386
Change-Id: I499efd98338beff6a27c03f03273331ecb6fd698
Reviewed-on: https://go-review.googlesource.com/4944
Reviewed-by: Minux Ma <minux@golang.org>
There is currently no way to ignore signals using the os/signal package.
It is possible to catch a signal and do nothing but this is not the same
as ignoring it. The new function Ignore allows a set of signals to be
ignored. The new function Reset allows the initial handlers for a set of
signals to be restored.
Fixes#5572
Change-Id: I5c0f07956971e3a9ff9b9d9631e6e3a08c20df15
Reviewed-on: https://go-review.googlesource.com/3580
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The new testdata was created by:
convert video-001.png -colorspace cmyk video-001.cmyk.jpeg
video-001.cmyk.jpeg was then converted back to video-001.cmyk.png via
the GIMP. ImageMagick (convert) wasn't used for this second conversion
because IM's default color profiles complicates things.
Fixes#4500.
Change-Id: Ibf533f6a6c7e76883acc493ce3a4289d7875df3f
Reviewed-on: https://go-review.googlesource.com/4801
Reviewed-by: Rob Pike <r@golang.org>
Change 85e7bee introduced a bug:
it marks map buckets as noscan when key and val do not contain pointers.
However, buckets with large/outline key or val do contain pointers.
This change takes key/val size into consideration when
marking buckets as noscan.
Change-Id: I7172a0df482657be39faa59e2579dd9f209cb54d
Reviewed-on: https://go-review.googlesource.com/4901
Reviewed-by: Keith Randall <khr@golang.org>
Some rounding modes are affected by the sign of the value to
be rounded. Make sure the sign is set before round is called.
Added tests (that failed before the fix).
Change-Id: Idd09b8fcbab89894fede0b9bc922cda5ddc87930
Reviewed-on: https://go-review.googlesource.com/4876
Reviewed-by: Rob Pike <r@golang.org>
e.g. ·Name instead of package·Name for automatic stack map to
be applied from its Go prototype.
The underlying reason is that liblink look up name with suffix
".args_stackmap" for the stackmap coming from its Go prototype,
but all the Go functions are named "".Name as this stage. Thus
an assembly function named package·Name will never find its
stackmap, which is named "".package.Name.args_stackmap.
Perhaps cmd/vet should give a warning for this.
Change-Id: I10d154a73ec969d574d20af877f747424350fbd1
Reviewed-on: https://go-review.googlesource.com/2588
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also: remove NewFloat - not needed anymore. Work-around for places
where has been used so far:
NewFloat(x, prec, mode) === new(Float).SetMode(mode).SetPrec(prec).SetFloat64(x)
However, if mode == ToNearestEven, SetMode is not needed. SetPrec
is needed if the default precision (53 after SetFloat64) is not
adequate.
TBR adonovan
Change-Id: Ifda12c479ba157f2dea306c32b47c7afbf31e759
Reviewed-on: https://go-review.googlesource.com/4842
Reviewed-by: Robert Griesemer <gri@golang.org>
Also:
- make representation more flexible (no need to store trailing 0 digits to match precision)
- simplify rounding as a consequence
- minor related fixes
TBR adonovan
Change-Id: Ie91075990688b506d28371ec3b633b8267397ebb
Reviewed-on: https://go-review.googlesource.com/4841
Reviewed-by: Rob Pike <r@golang.org>
The mechanical edit in the last round managed to miss ROUND1, among
other indgnities.
Change-Id: Ie3e19d00435a9e701b9872167e4bc7756a9fb5a5
Reviewed-on: https://go-review.googlesource.com/4870
Reviewed-by: Minux Ma <minux@golang.org>
Several .s files for ARM had several properties the new assembler will not support.
These include:
- mentioning SP or PC as a hardware register
These are always pseudo-registers except that in some contexts
they're not, and it's confusing because the context should not affect
which register you mean. Change the references to the hardware
registers to be explicit: R13 for SP, R15 for PC.
- constant creation using assignment
The files say a=b when they could instead say #define a b.
There is no reason to have both mechanisms.
- R(0) to refer to R0.
Some macros use this to a great extent. Again, it's easy just to
use a #define to rename a register.
Change-Id: I002335ace8e876c5b63c71c2560533eb835346d2
Reviewed-on: https://go-review.googlesource.com/4822
Reviewed-by: Dave Cheney <dave@cheney.net>
Per the comment at top, this test is about whether the GC runs during
init, but it was testing more than that, and testing how much the GC
collected in a certain amount of time.
Instead, loosen this test to just see whether it ran at all and not
how well it did.
Fixes#9848
Change-Id: I31da7dd769140d7b49aa6c149a543fae6076aa5e
Reviewed-on: https://go-review.googlesource.com/4820
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Android apps build again.
Defining TLSG in runtime/tls_arm.s gives it the type SNOPTRBSS, so its
type was never being set when GOOS=android. I considered modifying the
if statement, but I no longer understand the intention of the original
change (in d738c6b0ca). We were always setting it before, what
platform is this not valid for?
Fixes#9829
Change-Id: I3eaa4a9590893eff67695797eb22547a170cdbcd
Reviewed-on: https://go-review.googlesource.com/4834
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
The point of GOOBJ=2 was to have an active test of the cmd/internal/obj code.
Now we have end-to-end tests of the assembler, and soon the compiler,
so we don't need this halfway test on by default anymore.
(It's still possible to enable during debugging with the
environment variable.)
The problem it causes on the builders is that this particular testing
mode ends up with both the C process and the Go objwriter subprocess
having the same very large Prog list in memory simultaneously,
which causes basically a 2x memory blowup. In large programs
(such as the one generated by test/rotate.go) this is significant.
Disabling GOOBJ=2 should help with the current dev.cc builder
failures.
Change-Id: I1b11e4f29ea575659f02d2234242a904f7c867e4
Reviewed-on: https://go-review.googlesource.com/4832
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Make cmd/ld a real library invoked by the individual linkers.
There are no reverse symbol references anymore
(symbols referred to in cmd/ld but defined in cmd/5l etc).
This means that in principle we could do an automatic
conversion of these to Go, as a stopgap until cmd/link is done
or as a replacement for cmd/link.
Change-Id: I4a94570257a3a7acc31601bfe0fad9dea0aea054
Reviewed-on: https://go-review.googlesource.com/4649
Reviewed-by: Rob Pike <r@golang.org>
- remove a few uses of ? :
- rename variables named len
- rewrite a few gotos as nested switches
- move goto targets to scope allowed by Go
- use consistent return type of anyregalloc
(was int or int32 in different places)
- remove unused nr variable in agen
- include proper headers in generated builtin1.c
- avoid strange sized %E formats (%-6E, %2E)
- change gengcmask argument from uint8[16] to uint8*
(diagnosed by c2go; not an array in any real sense).
- replace #ifdef XXX with comment block in 5g/peep.c
- expand and remove FAIL macro from 5g
- expand and remove noimpl macro from 9g
- print regalloc errors to stdout in 8g
(only use of fprint(2, ...) in all compilers)
Still producing bit-for-bit identical output.
Change-Id: Id46efcd2a89241082b234f63f375b66f2754d695
Reviewed-on: https://go-review.googlesource.com/4646
Reviewed-by: Austin Clements <austin@google.com>
In mparith, all the a1-- are problematic. Rewrite it all without pointers.
It's clearer anyway.
In popt, v is problematic because it is used both as a fixed pointer
(v = byvar[i]) and as a moving pointer (v = var; v++) aka slice.
Eliminate pointer movement.
Tested that this still produces bit-for-bit output for 'go build -a std'
compared to d260756 (current master).
Change-Id: I1a1bed0f98b594c3864fe95075dd95f9b52113e0
Reviewed-on: https://go-review.googlesource.com/4645
Reviewed-by: Austin Clements <austin@google.com>
Otherwise the exported variable collides with the type Arch.
While we're here, remove arch.dumpit (now in portable code)
and add arch.defframe (forgotten originally, somehow).
Change-Id: I1b3a7dd7e96c5f632dba7cd6c1217b42a2004d72
Reviewed-on: https://go-review.googlesource.com/4644
Reviewed-by: Austin Clements <austin@google.com>
If the Go source says x.y, and x is undefined, today we get
undefined: x
Change to:
undefined: x in x.y
Change-Id: I8ea95503bd469ea933c6bcbd675b7122a5d454f3
Reviewed-on: https://go-review.googlesource.com/4643
Reviewed-by: Austin Clements <austin@google.com>
Even with debugmerge = 1, the debugging output only happens
with the -v command-line flag. This is useful because it gets added
in automatically when debugging things like registerization with -R -v.
Change-Id: I9a5c7f562507b72e8e2fe2686fd07d069721345a
Reviewed-on: https://go-review.googlesource.com/4641
Reviewed-by: Austin Clements <austin@google.com>
Noticed last week.
Just saw a strange build failure in the revised rcmp (called by qsort on region)
and this fixed it.
Submitting first to avoid finding out which of my pending CLs tickled the
problem.
Change-Id: I4cafd611e2bf8e813e57ad0025e48bde5ae54359
Reviewed-on: https://go-review.googlesource.com/4830
Reviewed-by: Russ Cox <rsc@golang.org>
When the compiler echoes back an expression, it shows the
generated yacc expression. Change the generated code to
use a slice so that $3 shows up as yyDollar[3] in such messages.
Consider changing testdata/expr/expr.y to say:
$$.Sub(float64($1), $3)
(The float64 conversion is incorrect.)
Before:
expr.y:70[expr.go:486]: cannot convert exprS[exprpt - 2].num (type *big.Rat) to type float64
After:
expr.y:70[expr.go:492]: cannot convert exprDollar[1].num (type *big.Rat) to type float64
Change-Id: I74e494069df588e62299d1fccb282f3658d8f8f4
Reviewed-on: https://go-review.googlesource.com/4630
Reviewed-by: Rob Pike <r@golang.org>
The current XML printer does not understand the xmlns
attribute. This change changes it so that it interprets the
xmlns attributes in the tokens being printed, and uses
appropriate prefixes.
Fixes#7535.
Change-Id: I20fae291d20602d37deb41ed42fab4c9a50ec85d
Reviewed-on: https://go-review.googlesource.com/2660
Reviewed-by: Nigel Tao <nigeltao@golang.org>
MOVQ RARG0, 0(SP) smashes exactly what was saved by PUSHQ R15.
This code managed to work somehow with the current race runtime,
but corrupts caller arguments with new race runtime that I am testing.
Change-Id: I9ffe8b5eee86451db36e99dbf4d11f320192e576
Reviewed-on: https://go-review.googlesource.com/4810
Reviewed-by: Keith Randall <khr@golang.org>
drainworkbuf is now gcDrain, since it drains until there's
nothing left to drain. drainobjects is now gcDrainN because it's
the bounded equivalent to gcDrain.
The new names use the Go camel case convention because we have to
start somewhere. The "gc" prefix is because we don't have runtime
packages yet and just "drain" is too ambiguous.
Change-Id: I88dbdf32e8ce4ce6c3b7e1f234664be9b76cb8fd
Reviewed-on: https://go-review.googlesource.com/4785
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
All calls to drainworkbuf now pass true for this argument, so remove
the argument and update the documentation to reflect the simplified
interface.
At a higher level, there are no longer any situations where we drain
"one wbuf" (though drainworkbuf didn't guarantee this anyway). We
either drain everything, or we drain a specific number of objects.
Change-Id: Ib7ee0fde56577eff64232ee1e711ec57c4361335
Reviewed-on: https://go-review.googlesource.com/4784
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
scanblock is only called during _GCscan and _GCmarktermination.
During _GCscan, scanblock didn't call drainworkbufs anyway. During
_GCmarktermination, there's really no point in draining some (largely
arbitrary) amount of work during the scanblock, since the GC is about
to drain everything anyway, so simply eliminate this case.
Change-Id: I7f3c59ce9186a83037c6f9e9b143181acd04c597
Reviewed-on: https://go-review.googlesource.com/4783
Reviewed-by: Russ Cox <rsc@golang.org>
scanblock(0, 0, nil, nil) was just a confusing way of saying
wbuf = getpartialorempty()
drainworkbuf(wbuf, true)
Make drainworkbuf accept a nil workbuf and perform the
getpartialorempty itself and replace all uses of scanblock(0, 0, nil,
nil) with direct calls to drainworkbuf(nil, true).
Change-Id: I7002a2f8f3eaf6aa85bbf17ccc81d7288acfef1c
Reviewed-on: https://go-review.googlesource.com/4781
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Previously, scanblock called checknocurrentwbuf() after
drainworkbuf(). Move this call into drainworkbuf so that every return
path from drainworkbuf calls checknocurrentwbuf(). This is equivalent
to the previous code because scanblock was the only caller of
drainworkbuf.
Change-Id: I96ef2168c8aa169bfc4d368f296342fa0fbeafb4
Reviewed-on: https://go-review.googlesource.com/4780
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently we always create context objects for closures that capture variables.
However, it is completely unnecessary for direct calls of closures
(whether it is func()(), defer func()() or go func()()).
This change transforms any OCALLFUNC(OCLOSURE) to normal function call.
Closed variables become function arguments.
This transformation is especially beneficial for go func(),
because we do not need to allocate context object on heap.
But it makes direct closure calls a bit faster as well (see BenchmarkClosureCall).
On implementation level it required to introduce yet another compiler pass.
However, the pass iterates only over xtop, so it should not be an issue.
Transformation consists of two parts: closure transformation and call site
transformation. We can't run these parts on different sides of escape analysis,
because tree state is inconsistent. We can do both parts during typecheck,
we don't know how to capture variables and don't have call site.
We can't do both parts during walk of OCALLFUNC, because we can walk
OCLOSURE body earlier.
So now capturevars pass only decides how to capture variables
(this info is required for escape analysis). New transformclosure
pass, that runs just before order/walk, does all transformations
of a closure. And later walk of OCALLFUNC(OCLOSURE) transforms call site.
benchmark old ns/op new ns/op delta
BenchmarkClosureCall 4.89 3.09 -36.81%
BenchmarkCreateGoroutinesCapture 1634 1294 -20.81%
benchmark old allocs new allocs delta
BenchmarkCreateGoroutinesCapture 6 2 -66.67%
benchmark old bytes new bytes delta
BenchmarkCreateGoroutinesCapture 176 48 -72.73%
Change-Id: Ic85e1706e18c3235cc45b3c0c031a9c1cdb7a40e
Reviewed-on: https://go-review.googlesource.com/4050
Reviewed-by: Russ Cox <rsc@golang.org>
The only remaining uses of four spaces instead of a tab is
when the line is too long (e.g. type Package).
Fixes#9809
Change-Id: Ifffd3639aa9264e795686ef1879a7686f182d2e5
Reviewed-on: https://go-review.googlesource.com/4182
Reviewed-by: Andrew Gerrand <adg@golang.org>
Using a zero register results in shorter, faster code.
5g already did this. Bring 6g, 8g, and 9g up to speed.
Reduces godoc binary size by 0.29% using 6g.
This CL includes cosmetic changes to 5g and 8g.
With those cosmetic changes included, componentgen is now
character-for-character equivalent across the four architectures.
Change-Id: I0e13dd48374bad830c725b117a1c86d4197d390c
Reviewed-on: https://go-review.googlesource.com/2606
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Fix a flipped nil check.
The flipped check prevented componentgen
from zeroing a non-cadable nl.
This fix reduces the number of non-SB LEAQs
in godoc from 35323 to 34920 (-1.1%).
Update #1914
Change-Id: I15ea303068835f606f883ddf4a2bb4cb2287e9ae
Reviewed-on: https://go-review.googlesource.com/2605
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Consider an interface value i of type I and concrete value c of type C.
Prior to this CL, i==c was evaluated as
I(c) == i
Evaluating I(c) can allocate.
This CL changes the evaluation of i==c to
x, ok := i.(C); ok && x == c
The new generated code is shorter and does not allocate directly.
If C is small, as it is in every instance in the stdlib,
the new code also uses less stack space
and makes one runtime call instead of two.
If C is very large, the original implementation is used.
The cutoff for "very large" is 1<<16,
following the stack vs heap cutoff used elsewhere.
This kind of comparison occurs in 38 places in the stdlib,
mostly in the net and os packages.
benchmark old ns/op new ns/op delta
BenchmarkEqEfaceConcrete 29.5 7.92 -73.15%
BenchmarkEqIfaceConcrete 32.1 7.90 -75.39%
BenchmarkNeEfaceConcrete 29.9 7.90 -73.58%
BenchmarkNeIfaceConcrete 35.9 7.90 -77.99%
Fixes#9370.
Change-Id: I7c4555950bcd6406ee5c613be1f2128da2c9a2b7
Reviewed-on: https://go-review.googlesource.com/2096
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
When compiling the stdlib most of the calls
to sgen are for exactly 2 or 3 words:
85% for 6g and 70% for 8g.
Special case them for performance.
This optimization is not relevant to 5g and 9g.
6g
benchmark old ns/op new ns/op delta
BenchmarkCopyFat16 3.25 0.82 -74.77%
BenchmarkCopyFat24 5.47 0.95 -82.63%
8g
benchmark old ns/op new ns/op delta
BenchmarkCopyFat8 3.84 2.42 -36.98%
BenchmarkCopyFat12 4.94 2.15 -56.48%
Change-Id: I8bc60b453f12597dfd916df2d072a7d5fc33ab85
Reviewed-on: https://go-review.googlesource.com/2607
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
When possible, generate nodl/nodr directly into DI/SI
rather than going through a temporary register.
CX has already been saved; use it during trailing bytes cleanup.
Change-Id: I4ec6209bcc5d3bfdc927c5c132009bd8d791ada3
Reviewed-on: https://go-review.googlesource.com/2608
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
No code modifications.
This is in preparation for improving the wbuf abstraction.
Change-Id: I719543a345c34d079b7e39b251eccd5dd8a07826
Reviewed-on: https://go-review.googlesource.com/4710
Reviewed-by: Rick Hudson <rlh@golang.org>
Plan 9's sysFree has an optimization where if the object being freed
is the last object allocated, it will roll back the brk to allow the
memory to be reused by sysAlloc. However, it does not zero this
"returned" memory, so as a result, sysAlloc can return non-zeroed
memory after a sysFree. This leads to corruption because the runtime
assumes sysAlloc returns zeroed memory.
Fix this by zeroing the memory returned by sysFree.
Fixes#9846.
Change-Id: Id328c58236eb7c464b31ac1da376a0b757a5dc6a
Reviewed-on: https://go-review.googlesource.com/4700
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: David du Colombier <0intro@gmail.com>
Dump frames of functions.
Add function name and var width to output.
Change-Id: Ida06b8def96178fa550ca90836eb4a2509b9e13f
Reviewed-on: https://go-review.googlesource.com/3870
Reviewed-by: Russ Cox <rsc@golang.org>
typedslicecopy is another write barrier that is not
understood by racewalk. It seems quite complex to handle it
in the compiler, so instead just instrument it in runtime.
Update #9796
Change-Id: I0eb6abf3a2cd2491a338fab5f7da22f01bf7e89b
Reviewed-on: https://go-review.googlesource.com/4370
Reviewed-by: Russ Cox <rsc@golang.org>
Walk calls it outervalue, racewalk calls it basenod,
isstack does it manually and slightly differently.
Change-Id: Id5b5d32b8faf143fe9d34bd08457bfab6fb33daa
Reviewed-on: https://go-review.googlesource.com/3745
Reviewed-by: Russ Cox <rsc@golang.org>
Support the following conversions in escape analysis:
[]rune("foo")
[]byte("foo")
string([]rune{})
If the result does not escape, allocate temp buffer on stack
and pass it to runtime functions.
Change-Id: I1d075907eab8b0109ad7ad1878104b02b3d5c690
Reviewed-on: https://go-review.googlesource.com/3590
Reviewed-by: Russ Cox <rsc@golang.org>
Now:
0x0000 00000 (/tmp/x.s:2) MULLU R6,R3,(R7, R6)
The space is a little odd but I'd rather fix the usual printing to add spaces
than delete that one. But in a different CL, once C is gone.
Change-Id: I344e0b06eedaaf53cd79d370fa13c444a1e69c81
Reviewed-on: https://go-review.googlesource.com/4647
Reviewed-by: Rob Pike <r@golang.org>
(In non-Go print formats, the 016 includes the leading 0x prefix.
No one noticed, but we were printing hex numbers with a minimum
of 30 digits, not 32.)
Change-Id: I10ff7a51a567ad7c8440418ac034be9e4b2d6bc1
Reviewed-on: https://go-review.googlesource.com/4592
Reviewed-by: Austin Clements <austin@google.com>
This matches all the other pseudo-packages.
The line was simply forgotten.
Change-Id: I278f6cbcfc883ea7efad07f99fc8c853b9b5d274
Reviewed-on: https://go-review.googlesource.com/4591
Reviewed-by: Austin Clements <austin@google.com>
Otherwise different qsort implementations might result
in different sort orders and therefore different compiled
object files.
Change-Id: Ie783ba55a55af06941307e150b0c406e0a8128b0
Reviewed-on: https://go-review.googlesource.com/4590
Reviewed-by: Austin Clements <austin@google.com>
It does not convert to Go well.
Being able to do this just once, instead of 4 times, was the primary
motivation for all the recent refactoring (not that it wasn't overdue).
Still bit-for-bit identical.
Change-Id: Ia01f17948441bf64fa78ec4226f0bb40af0bbaab
Reviewed-on: https://go-review.googlesource.com/3962
Reviewed-by: Austin Clements <austin@google.com>
Now there is only one registerizer shared among all the systems.
There are some unfortunate special cases based on arch.thechar
in reg.c, to preserve bit-for-bit compatibility during the refactoring.
Most are probably bugs one way or another and should be revisited.
Change-Id: I153b435c0eaa05bbbeaf8876822eeb6dedaae3cf
Reviewed-on: https://go-review.googlesource.com/3883
Reviewed-by: Austin Clements <austin@google.com>
gc/order.c rewrites OASOP nodes into ordinary assignments.
The back ends never see them anymore.
Change-Id: I268ac8bdc92dccd7123110a21f99ada3ceeb2baa
Reviewed-on: https://go-review.googlesource.com/3882
Reviewed-by: Austin Clements <austin@google.com>
This isn't everything, but it's a start.
Still producing bit-identical compiler output.
The semantics of the old back ends is preserved,
even when they are probably buggy.
There are some TODOs in gc/gsubr.c to
remove special cases to preserve bugs in 5g and 8g.
Change-Id: I28ae295fbfc94ef9df43e13ab96bd6fc2f194bc4
Reviewed-on: https://go-review.googlesource.com/3802
Reviewed-by: Austin Clements <austin@google.com>
Add local workbufs to the m struct in order to reduce contention.
Add consistency checks for workbuf ownership.
Chain workbufs through call change to avoid swapping them
to and from the m struct.
Adjust the size of the workbuf so that the mutators can
more frequently pass modifications to the GC thus shifting
some work from the STW mark termination phase to the concurrent
mark phase.
Change-Id: I557b53af34ad9972265e0ed9f5996e52d548563d
Reviewed-on: https://go-review.googlesource.com/3972
Reviewed-by: Austin Clements <austin@google.com>
Fixes#9791
g.issystem flag setup races with other code wherever we set it.
Even if we set both in parent goroutine and in the system goroutine,
it is still possible that some other goroutine crashes
before the flag is set. We could pass issystem flag to newproc1,
but we start all goroutines with go nowadays.
Instead look at g.startpc to distinguish system goroutines (similar to topofstack).
Change-Id: Ia3467968dee27fa07d9fecedd4c2b00928f26645
Reviewed-on: https://go-review.googlesource.com/4113
Reviewed-by: Keith Randall <khr@golang.org>
Update #8832
This is probably not the root cause of the issue.
Resolve TODO about setting unusedsince on a wrong span.
Change-Id: I69c87e3d93cb025e3e6fa80a8cffba6ad6ad1395
Reviewed-on: https://go-review.googlesource.com/4390
Reviewed-by: Keith Randall <khr@golang.org>
Currently, if there is a VERSION.cache, running make.bash will set
runtime.theVersion to the revision as of the *last* make.bash run
instead of the current make.bash run.
For example,
$ git rev-parse --short HEAD
5c4a86d
$ ./make.bash
...
$ cat ../VERSION.cache
devel +5c4a86d Tue Feb 10 01:46:30 2015 +0000
$ git checkout a1dbb92
$ ./make.bash
...
$ go version
go version devel +5c4a86d Tue Feb 10 01:46:30 2015 +0000 linux/amd64
$ ./make.bash
...
$ go version
go version devel +a1dbb92 Tue Feb 10 02:31:27 2015 +0000 linux/amd64
This happens because go tool dist reads the potentially stale
VERSION.cache into goversion during early initialization; then cleans,
which deletes VERSION.cache; then builds the runtime using the stale
revision read in to goversion. It isn't until make later in the build
process, when make.bash invokes go tool dist again, that VERSION.cache
gets updated with the current revision.
To address this, simply don't bother fetching the version until go
tool dist needs it and don't bother caching the value in memory. This
is more robust since it interacts with cleaning in the expected ways.
Futhermore, there's no downside to eliminating the in-memory cache;
the file system cache is perfectly reasonable for the whole three
times make.bash consults it.
Change-Id: I8c480100e56bb2db0816e8a088177004d9e87973
Reviewed-on: https://go-review.googlesource.com/4540
Reviewed-by: Russ Cox <rsc@golang.org>
- obj: add a missing setting of the context for a generated JMP instruction
- asm: correct the encoding of mode (R)(R*scale)
- asm: fix a silly bug in the test for macro recursion.
- asm: accept address mode sym(R)(R*8); was an oversight
Change-Id: I27112eaaa1faa0d2ba97e414f0571b70733ea087
Reviewed-on: https://go-review.googlesource.com/4502
Reviewed-by: Russ Cox <rsc@golang.org>
If an absolute domain name (i.e. ends in a '.' like "example.com.") is used
with ssl/tls, the certificate will be reported as invalid. In matchHostnames,
the host and patterns are split on '.' and if the lengths of the resulting
slices do not match, the function returns false. When splitting an absolute
domain name on '.', the slice will have an extra empty string at the end. This
empty string should be discarded before comparison, if present.
Fixes#9828
Change-Id: I0e39674b44a6f93b5024497e76cf1b550832a61d
Reviewed-on: https://go-review.googlesource.com/4380
Reviewed-by: Adam Langley <agl@golang.org>
TryBot: Adam Langley <agl@golang.org>
Container symbols shouldn't be considered as functions in the functab.
Having them present probably messes up function lookup, as you might get
the descriptor of the container instead of the descriptor of the actual
function on the stack. It also messed up the findfunctab because these
entries caused off-by-one errors in how functab entries were counted.
Normal code is not affected - it only changes (& hopefully fixes) the
behavior for libraries linked as a unit, like:
net
runtime/cgo
runtime/race
Fixes#9804
Change-Id: I81e036e897571ac96567d59e1f1d7f058ca75e85
Reviewed-on: https://go-review.googlesource.com/4290
Reviewed-by: Russ Cox <rsc@golang.org>
- Frexp, Ldexp are equivalents to the corresponding math functions.
- Set now has the same prec behavior as the other functions
- Copy is a true assignment (replaces old version of Set)
- Cmp now handles infinities
- more tests
Change-Id: I0d33980c08be3095b25d7b3d16bcad1aa7abbd0f
Reviewed-on: https://go-review.googlesource.com/4292
Reviewed-by: Alan Donovan <adonovan@google.com>
The sanity checks at the beginning of WriteMsgUDP were too
strict, and did not allow a case sendmsg(2) suppports: sending
to a connected UDP socket.
This fixes the sanity checks. Either the socket is unconnected,
and a destination addresses is required (what all existing callers
must have been doing), or the socket is connected and an explicit
destination address must not be used.
Fixes#9807
Change-Id: I08d4ec3c2bf830335c402acfc0680c841cfcec71
Reviewed-on: https://go-review.googlesource.com/3951
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
I think the test was meant to test requests to 'localhost:80' instead
of 'localhost:80:80'. It passes even with 'localhost:80:80' because
net.SplitHostPort fails inside useProxy. Please comment if you want to
leave old 'localhost:80' is the list too to check old code path.
Change-Id: Ic4cd21901563449e3d4e2f4c8caf723f4ca15bac
u
Reviewed-on: https://go-review.googlesource.com/4293
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL introduces new methods for 'context' type, so we can
manipulate its values in an architecture independent way.
Use new methods to replace both 386 and amd64 versions of
dosigprof with single piece of code.
There is more similar code to be converted in the following CLs.
Also remove os_windows_386.go and os_windows_amd64.go. These
contain unused functions.
Change-Id: I28f76aeb97f6e4249843d30d3d0c33fb233d3f7f
Reviewed-on: https://go-review.googlesource.com/2790
Reviewed-by: Minux Ma <minux@golang.org>
I am an idiot but the failure to implement this means we can decide
exactly what its design should be for 1.5
Change-Id: Ie2b025fcd899d306ddeddd09d1d0e8f9a99ab7a8
Reviewed-on: https://go-review.googlesource.com/4291
Reviewed-by: Minux Ma <minux@golang.org>
Fixes#9732Fixes#9819
Rather than detecting vfp support via catching SIGILL signals,
parse the contents of /proc/cpuinfo.
As the GOARM values for NaCl and freebsd are hard coded, this parsing
logic only needs to support linux/arm.
This change also fixes the nacl/arm build which is broken because the
first stage of nacltest.bash is executed with GOARM=5, embedding that
into 5g.
The second stage of nacltest.bash correctly detects GOARM=7, but this is
ignored as we pass --no-clean at that point, and thus do not replace
the compiler.
Lastyly, include a fix to error message in nacltest.bash
Change-Id: I13f306ff07a99b44b493fade72ac00d0d5097e1c
Reviewed-on: https://go-review.googlesource.com/3981
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 2118 makes the assumption that all references to runtime.tlsg
should be accompanied by a declaration of runtime.tlsg if its type
should be a normal variable, instead of a placeholder for TLS
relocation.
Because if runtime.tlsg is not declared by the runtime package,
the type of runtime.tlsg will be zero, so fix the check in liblink
to look for 0 instead of STLSBSS (the type will be initialized by
cmd/ld, but cmd/ld doesn't run during assembly).
Change-Id: I691ac5c3faea902f8b9a0b963e781b22e7b269a7
Reviewed-on: https://go-review.googlesource.com/4030
Reviewed-by: David Crawshaw <crawshaw@golang.org>
These illegal addressing modes were caught downstream in the assembler
or link library, but we can give a better error message upstream.
Change-Id: Ib30ef4d94d5d8d44900276592edd7997e6f91e55
Reviewed-on: https://go-review.googlesource.com/4260
Reviewed-by: Russ Cox <rsc@golang.org>
Considerable rewriting of the parser and assembler (code generator)
but it's simpler and shorter now. The internal Addr type is gone; so
is the package that held it. Parsing of operands goes directly into
obj.Addrs now.
There is a horrible hack regarding register pairs. It uses the Class
field to store the second register since it needs _some_ place to
put it but none is provided in the API. An alternative would be nice
but this works for now.
Once again creates identical .6 and .8 files as the old assembler.
Change-Id: I8207d6dfdfdb5bbed0bd870cb34ee0fe61c2fbfd
Reviewed-on: https://go-review.googlesource.com/4062
Reviewed-by: Russ Cox <rsc@golang.org>
"go test -v" buffers output if more than one package is
being tested to avoid mixing the outputs from multiple
tests running in parallel. It currently enables streaming
if there's only a single package under test.
It is ok to stream output from multiple tests if we know
that they're not going to be running in parallel.
To see the difference: go test -v -p=1 runtime fmt -short
Change-Id: Idc24575c899eac30d553e0bf52b86f90e189392d
Reviewed-on: https://go-review.googlesource.com/4153
Reviewed-by: Ian Lance Taylor <iant@golang.org>
- better and more consistent documentation
- more functions implemented
- more tests
Change-Id: If4c591e7af4ec5434fbb411a48dd0f8add993720
Reviewed-on: https://go-review.googlesource.com/4140
Reviewed-by: Alan Donovan <adonovan@google.com>
This is an alternative to http://golang.org/cl/4150,
and is motivated by a review comment on that CL.
testKillProcess() tries to build and run the Go equivalent
for "sleep 1". This doesn't work for testing cross compilers
since the Go compiler is not available on the targets. This
change embeds the "sleep 1" functionality within the "os.test"
binary itself.
Change-Id: I6bad513deaa6c9e2704e70319098eb4983f1bb23
Reviewed-on: https://go-review.googlesource.com/4190
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If we cannot load timezone information for a reason other than the
zoneinfo file not existing, return it since that will be much more
useful in debugging failures than "unknown time zone XYZ".
Fixes#9723.
Change-Id: I3aa5774859cec28e584d16bcc1fef0705d95288c
Reviewed-on: https://go-review.googlesource.com/3984
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reverts https://golang.org/cl/119530044 (OS X 10.10 Yosemite beta
14A299l workaround), since it was fixed in the final Yosemite release.
I verified that the C program http://swtch.com/~rsc/readdirbug.c
passes on Yosemite.
Adds a new test to the os package too, to verify that reading a
regular file as a directory fails.
Fixes#9789 (ReadDir: no error if dirname is a file)
Change-Id: I75286cef88fbb2ebccf045b479e33c810749dcbc
Reviewed-on: https://go-review.googlesource.com/4164
Reviewed-by: Dave Cheney <dave@cheney.net>
Before, an array of size 4 would always be allocated even if a tag
doesn't have any attributes. Now that array is allocated only if
needed.
benchmark old allocs new allocs delta
BenchmarkUnmarshal 191 176 -8.5%
Change-Id: I4d214b228883d0a6e892c0d6eb00dfe2da84c116
Reviewed-on: https://go-review.googlesource.com/4160
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change is an implementation of the signal
runtime and os/signal package on Plan 9.
Contrary to Unix, on Plan 9 a signal is called
a note and is represented by a string.
For this reason, the sigsend and signal_recv
functions had to be reimplemented specifically
for Plan 9.
In order to reuse most of the code and internal
interface of the os/signal package, the note
strings are mapped to integers.
Thanks to Russ Cox for the early review.
Change-Id: I95836645efe21942bb1939f43f87fb3c0eaaef1a
Reviewed-on: https://go-review.googlesource.com/2164
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
It turns out -iex argument is not supported by all gdb versions,
but as we need to add the auto-load safe path before loading the
inferior, test -iex support first and skip the test if it's not
available.
We should still update our builders though.
Change-Id: I355697de51baf12162ba6cb82f389dad93f93dc5
Reviewed-on: https://go-review.googlesource.com/4070
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On some systems, gdb refuses to load Python plugin from arbitrary
paths, so we have to add $GOROOT/src/runtime to auto-load-safe-path
in the gdb script test.
Change-Id: Icc44baab8d04a65bd21ceac2ab8ddb13c8d083e8
Reviewed-on: https://go-review.googlesource.com/2905
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Ideally, those methods should return a copy of the Addr, but
due to the Go 1 API guarantee, we cannot make that change now:
there might exist client code that uses the returned Addr as
map index and thus relies on the fact that different invocation
of the method returns the same pointer. Changing this behavior
will lead to hidden behaviour change in those programs.
Update #9654.
Change-Id: Iad4235f2ed7789b3a3c8e0993b9718cf0534ea2b
Reviewed-on: https://go-review.googlesource.com/3851
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ordinary switch statements are rewritten
into a sequence of if statements.
Staticly dead cases were not being eliminated
because the rewrite introduced a temporary,
which hid the fact that the case was a constant.
Stop doing that.
This eliminates dead code in the standard library at:
runtime/cgocall.go:219
runtime/cgocall.go:269
debug/gosym/pclntab.go:175
debug/macho/file.go:208
math/big/nat.go:635
math/big/nat.go:850
math/big/nat.go:1058
cmd/pprof/internal/commands/commands.go:86
net/sock_bsd.go:19
cmd/go/build.go:2657
cmd/go/env.go:90
Fixes#9608.
Change-Id: Ic23a05dfbb1ad91d5f62a6506b35a13e51b33e38
Reviewed-on: https://go-review.googlesource.com/3980
Reviewed-by: Keith Randall <khr@golang.org>
eqstring does not need to check the length of the strings.
Other architectures were done in a separate commit.
While we're here, add a pointer equality check.
Change-Id: Id2c8616a03a7da7037c1e9ccd56a549fc952bd98
Reviewed-on: https://go-review.googlesource.com/3956
Reviewed-by: Keith Randall <khr@golang.org>
eqstring does not need to check the length of the strings.
6g
benchmark old ns/op new ns/op delta
BenchmarkCompareStringEqual 7.03 6.14 -12.66%
BenchmarkCompareStringIdentical 3.36 3.04 -9.52%
5g
benchmark old ns/op new ns/op delta
BenchmarkCompareStringEqual 238 232 -2.52%
BenchmarkCompareStringIdentical 90.8 80.7 -11.12%
The equivalent PPC changes are in a separate commit
because I don't have the hardware to test them.
Change-Id: I292874324b9bbd9d24f57a390cfff8b550cdd53c
Reviewed-on: https://go-review.googlesource.com/3955
Reviewed-by: Keith Randall <khr@golang.org>
- clarified representation of +/-Inf
- only 0 and Inf values can have 0 precision
- a zero precision value used as result value takes the max precision
of the arguments (to be fine-tuned for setters)
- the zero precision approach makes Float zero values possible
(they represent +0)
- more tests
Missing: Filling in the blanks. More tests.
Change-Id: Ibb4f97e12e1f356c3085ce80f3464e97b82ac130
Reviewed-on: https://go-review.googlesource.com/4000
Reviewed-by: Alan Donovan <adonovan@google.com>
Only documentation / comment changes. Update references to
point to golang.org permalinks or go.googlesource.com/go.
References in historical release notes under doc are left as is.
Change-Id: Icfc14e4998723e2c2d48f9877a91c5abef6794ea
Reviewed-on: https://go-review.googlesource.com/4060
Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/dist: recognize darwin/arm as (host) goos/goarches. also hard
code GOARM=7 for darwin/arm.
make.bash: don't pass -mmacosx-version-min=10.6 when building for
darwin/arm.
Change-Id: If0ecd84a5179cd9bb61b801ac1899adc45f12f75
Reviewed-on: https://go-review.googlesource.com/2126
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
On Darwin/ARM, because libSystem doesn't provide functions for
__sync_fetch_and_add, and only clang can inline that function,
skip the test when building with GCC.
Change-Id: Id5e9d8f9bbe1e6bcb2f381f0f66cf68aa95277c7
Reviewed-on: https://go-review.googlesource.com/2125
Reviewed-by: Ian Lance Taylor <iant@golang.org>
liblink:
- set dummy value for ctxt->tlsoffset.
cmd/ld:
- always do external linking when using cgo on darwin/arm,
as our linker might not generate codesign-compatible binary.
cmd/5l:
- support generate ARM Mach-O binaries
- add machoreloc1() that translate our internal relocation to
macho relocations used by external linking.
Change-Id: Ic5454aeb87009aaf8f1453ec7fe33e6da55d5f06
Reviewed-on: https://go-review.googlesource.com/3273
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Libc on Darwin/ARM has a buggy implementation of ldexp and frexp
that could not handle denormal numbers.
Also disable VFP runfast (flush-to-zero) mode so that the gc
compiler can correctly handle denormal constants used in math and
strconv tests.
Change-Id: Ie64220b882f414e0b37f406f38181c3586104d46
Reviewed-on: https://go-review.googlesource.com/2119
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
In the old code, liblink, cmd/ld and runtime all have code determine
whether runtime.tlsg is an actual variable or a placeholder for TLS
relocation. This change consolidate them into one: the runtime/tls_arm.s
will ultimately determine the type of that variable.
Change-Id: I3b3f80791a1db4c2b7318f81a115972cd2237e43
Reviewed-on: https://go-review.googlesource.com/2118
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
The main issue is that the misc/cgo/{stdio,life} tests are silently
getting skipped when invoked from run.bash.
run.go should ignore any build tags after the first blank line in
source file. It already checks for test actions only upto the first
blank line. Build tags must be specified in the same block.
See http://golang.org/cl/3675 for background.
Change-Id: Id8abf000119e3335f7250d8ef34aac7811fc9dff
Reviewed-on: https://go-review.googlesource.com/3812
Reviewed-by: Minux Ma <minux@golang.org>
issue9355 generated a file a.[568] in test/ directory and left it there.
For tests like these, it is best to chdir to a test specific directory
before generating any temporary files, since the tests are running
in parallel and might otherwise race with each other for the same files.
Change-Id: I58d96256d4d8ee3fda70d81077f19006064a7425
Reviewed-on: https://go-review.googlesource.com/3813
Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/internal/obj reconverted using rsc.io/c2go rev 2a95256.
- Brings in new, more regular Prog, Addr definitions
- Add Prog* argument to oclass in liblink/asm[68].c, for c2go conversion.
- Update objwriter for change in TEXT size encoding.
- Merge 5a, 6a, 8a, 9a changes into new5a, new6a, new8a, new9a (by hand).
- Add +build ignore to cmd/asm/internal/{addr,arch,asm}, cmd/asm.
They need to be updated for the changes.
- Reenable verifyAsm in cmd/go.
- Reenable GOOBJ=2 mode by default in liblink.
All architectures build successfully again.
Change-Id: I2c845c5d365aa484b570476898171bee657b626d
Reviewed-on: https://go-review.googlesource.com/3963
Reviewed-by: Rob Pike <r@golang.org>
This was working when 5a was built on x86 because REG_R0 = 32,
and a 32-bit shift on x86 uses only the low 32 bits of the shift count.
On ARM, the shift clamping is different.
Moving to Go will avoid these differing shift semantics.
I tripped over and fixed this bug in new5a the same way earlier tonight.
Change-Id: Id56aa0bb1830ccf250960f843e0acb8a0409e87d
Reviewed-on: https://go-review.googlesource.com/3961
Reviewed-by: Dave Cheney <dave@cheney.net>
These benchmarks are only for functions commonly used in loops. The
other functions are typically used for inspection or setup and thus are
not performance sensitive.
Change-Id: I8d0a0ba2d8234ecacb40fa3aa9077bf93c8fe89c
Reviewed-on: https://go-review.googlesource.com/3680
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
(For zero values the strconv %b format prints the bias-adjusted exponent;
there's no bias in Float.)
Change-Id: I6f4dda9c3a50d02eac375cfe2c927c1540aae865
Reviewed-on: https://go-review.googlesource.com/3841
Reviewed-by: Alan Donovan <adonovan@google.com>
The upcoming merge is going to break the synchrony.
Will restore separately.
Change-Id: I90946119a0901e24063b190d1a074594af7654c7
Reviewed-on: https://go-review.googlesource.com/3888
Reviewed-by: Russ Cox <rsc@golang.org>
In android-L, logging is done through the logd daemon.
If logd daemon is available, send logging to logd.
Otherwise, fallback to the legacy mechanism (/dev/log files).
This change adds access/socket/connect calls to interact with the logd.
Fixesgolang/go#9398.
Change-Id: I3c52b81b451f5862107d7c675f799fc85548486d
Reviewed-on: https://go-review.googlesource.com/3350
Reviewed-by: David Crawshaw <crawshaw@golang.org>
An editing error prevented the tables from being set up correctly.
With that fixed, asm is now compatible with 8a.
Change-Id: Ieb20e6dcaf4c05bd448ea748a010ee1f58ef4807
Reviewed-on: https://go-review.googlesource.com/3867
Reviewed-by: Russ Cox <rsc@golang.org>
Add Addr-checking for all Progs on input to liblink, in liblink/pass.c,
including requiring use of TYPE_ADDR, not TYPE_CONST.
Update compilers and assemblers to satisfy checks.
Change-Id: Idac36b9f6805f0451cb541d2338992ca5eaf3963
Reviewed-on: https://go-review.googlesource.com/3801
Reviewed-by: Austin Clements <austin@google.com>
Generating array types like [4]int would fail even though the int type
is generatable. Allow generating values of array types when the inner
type is generatable.
Change-Id: I7d71b3c18edb3737e2fec1ddf5e36c9dc8401971
Reviewed-on: https://go-review.googlesource.com/3865
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The unbounded list-based defer pool can grow infinitely.
This can happen if a goroutine routinely allocates a defer;
then blocks on one P; and then unblocked, scheduled and
frees the defer on another P.
The scenario was reported on golang-nuts list.
We've been here several times. Any unbounded local caches
are bad and grow to infinite size. This change introduces
central defer pool; local pools become fixed-size
with the only purpose of amortizing accesses to the
central pool.
Change-Id: Iadcfb113ccecf912e1b64afc07926f0de9de2248
Reviewed-on: https://go-review.googlesource.com/3741
Reviewed-by: Keith Randall <khr@golang.org>
Using benchmark from the issue:
benchmark old ns/op new ns/op delta
BenchmarkRangeStringCast 2162 1152 -46.72%
benchmark old allocs new allocs delta
BenchmarkRangeStringCast 1 0 -100.00%
Fixes#2204
Change-Id: I92c5edd2adca4a7b6fba00713a581bf49dc59afe
Reviewed-on: https://go-review.googlesource.com/3790
Reviewed-by: Keith Randall <khr@golang.org>
Before 3c0fee1, runtime.gogo was just long enough to align to 64 bytes
on OSs with short get_tls implementations and 80 bytes on OSs with
longer get_tls implementations (Windows, Solaris, and Plan 9).
3c0fee1 added a few instructions, which pushed it to 80 on most OSs,
including Windows and Plan 9, and 96 on Solaris.
Fixes#9770.
Change-Id: Ie84810657c14ab16dce9f0e0a932955251b0bf33
Reviewed-on: https://go-review.googlesource.com/3850
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
golang.org/cl/144110044 made _ consts treated
as exported as a small, safe fix for #5397.
It also introduced issue #9615.
golang.org/cl/2091 then fixed the underlying issue,
which was missing type information when the type
was specified only for _.
This cl reverts the original fix.
Fixes#9615.
Change-Id: I4815ad8292bb5bec18beb8c131b48949d9af8876
Reviewed-on: https://go-review.googlesource.com/3832
Reviewed-by: Robert Griesemer <gri@golang.org>
Generalizes PRF calculation for TLS 1.2 to support arbitrary hashes (SHA-384 instead of SHA-256).
Testdata were all updated to correspond with the new cipher suites in the handshake.
Change-Id: I3d9fc48c19d1043899e38255a53c80dc952ee08f
Reviewed-on: https://go-review.googlesource.com/3265
Reviewed-by: Adam Langley <agl@golang.org>
%r format prints nothing useful on windows (see issue 9722).
Hopefully this will provide more clues about what happened.
Change-Id: Ic553bbdcde0c3cbfffa3a28f2168d6e75694e2ac
Reviewed-on: https://go-review.googlesource.com/3568
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Additional elements in a DN can be added in via ExtraNames. This
option can also be used for sorting DN elements in a custom order.
Change-Id: Ie408d332de913dc2a33bdd86433be38abb7b55be
Reviewed-on: https://go-review.googlesource.com/2257
Reviewed-by: Adam Langley <agl@golang.org>
A typo limited the number of center-dot substitutions to one. Fixed.
With these changes, plus a recent fix to 6a, the are no differences,
down to the bit level, in object code for any assembly files in std
between asm and 6a. (Runtime has not been checked yet, but I
expect no errors.)
Change-Id: I0e8045b4414223d937e7f8919c8768860554b7d5
Reviewed-on: https://go-review.googlesource.com/3820
Reviewed-by: Russ Cox <rsc@golang.org>
Use memprofilerate in GODEBUG instead of memprofrate to be
consistent with other uses.
Change-Id: Iaf6bd3b378b1fc45d36ecde32f3ad4e63ca1e86b
Reviewed-on: https://go-review.googlesource.com/3800
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This makes names like ANOP, ATEXT, AGLOBL, ACALL, AJMP, ARET
available for use by architecture-independent processing passes.
On arm and ppc64, the alternate names are now aliases for the
official ones (ABL for ACALL, AB or ABR for AJMP, ARETURN for ARET).
Change-Id: Id027771243795af2b3745199c645b6e1bedd7d18
Reviewed-on: https://go-review.googlesource.com/3577
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: Austin Clements <austin@google.com>
Like the TEXT/GLOBL flags, this was split between from.scale and reg,
neither of which is appropriate.
Change-Id: I2a16ef066a53b6edb7afb16cce108c0d1d26389c
Reviewed-on: https://go-review.googlesource.com/3576
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: Austin Clements <austin@google.com>
Use AXXX instead of AGOK (neither is a valid instruction but AXXX is zero)
for the initial setting of Prog.as, and now there are no non-zero default
field settings.
Remove the arch-specific zprog/zprg in favor of a single global zprog.
Remove the arch-specific prg constructor in favor of emallocz(sizeof(Prog)).
Change-Id: Ia73078726768333d7cdba296f548170c1bea9498
Reviewed-on: https://go-review.googlesource.com/3575
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: Austin Clements <austin@google.com>
Originally, when this code was part of 6l/8l, every new
Prog was constructed starting with zprg, which set back=2,
and then this code walked over the list setting back=1 for
backward branches, back=0 otherwise. The initial back=2
setting was used to identify forward branches (the branched-to
instruction had back == 2 since it hadn't yet been set to 0 or 1).
When the code was extracted into liblink and linked directly
with 6a/6g/8a/8g, those programs created the Prog struct
and did not set back=2, breaking this backward branch detection.
No one noticed, because the next loop recomputes the information.
The only requirement for the next loop is that p->back == 0 or 1 for
each of the Progs in the list.
The initialization of the zprg with back=2 would cause problems
in this second loop, for the few liblink-internally-generated instructions
that are created by copying zprg, except that the first loop was
making sure that back == 0 or 1.
The first loop's manipulation of p->back can thus be deleted,
provided we also delete the zprg.back = 2 initializations.
This is awful and my fault. I apologize.
While we're here, remove the .scale = 1 from the zprg init too.
Anything that sets up a scaled index should set the scale itself.
(And mostly those come from outside liblink anyway.)
Tested by checking that all generated code is bit-for-bit
identical to before this CL.
Change-Id: I7f6e0b33ce9ccd5b7dc25e0f00429fedd0957c8c
Reviewed-on: https://go-review.googlesource.com/3574
Reviewed-by: Austin Clements <austin@google.com>
Before, amd64 and 386 stored the flags in p->from.scale
and arm and ppc64 stored the flags in p->reg.
Both caused special cases in printing and in handling of the
addresses.
To avoid possible conflicts with the real meaning of p->from
and to avoid storing a non-register value in a reg field,
use from3 to hold a TYPE_CONST value giving the flags.
There is still a special case for printing, because the flags
are specified without a $, and normally a TYPE_CONST prints
with a $. But that's much less special than what came before.
This allows us to remove the textflag and settextflag methods
from LinkArch. They are no longer architecture-specific.
Change-Id: I931da8e1ecd92e127cd9aa44ef5a73c42e730110
Reviewed-on: https://go-review.googlesource.com/3572
Reviewed-by: Austin Clements <austin@google.com>
Because it was lumped in with the TEXT instruction,
the high 32 bits of the 64-bit constant holding the size
were always set to 0x80000000 (ArgsSizeUnknown).
This only worked because cmd/9l was reading the 64-bit
value into an int32.
While we're here, fix 5a.
It wasn't as much of a problem there because
the two values were being stored in two different fields.
But it was still wrong.
Change-Id: I69a2214c7be939530d499e29cfdc3b26720ac05a
Reviewed-on: https://go-review.googlesource.com/3570
Reviewed-by: Austin Clements <austin@google.com>
Lines beginning with #ifdef, #else, #endif were not incrementing
the line number, resulting in bad line number information for
assembly files with #ifdefs.
Example:
#ifndef GOARCH_ppc64
#endif
#ifdef GOARCH_ppc64le
#endif
TEXT ·use(SB),7,$0
RET
Before this change, the line number recorded for use in 6a -S output
(and in the runtime information in the binary) was 4 too low.
Change-Id: I23e599112ec9919f72e53ac82d9bebbbae3439ed
Reviewed-on: https://go-review.googlesource.com/3783
Reviewed-by: Rob Pike <r@golang.org>
Kindly detected by race builders by failing TestRaceRange.
ORANGE typecheck does not increment decldepth around body.
Change-Id: I0df5f310cb3370a904c94d9647a9cf0f15729075
Reviewed-on: https://go-review.googlesource.com/3507
Reviewed-by: Russ Cox <rsc@golang.org>
Type switch variables was not typechecked.
Previously it lead only to a minor consequence:
switch unsafe.Sizeof = x.(type) {
generated an inconsistent error message.
But capturing by value functionality now requries typechecking of all ONAMEs.
Fixes#9731
Change-Id: If037883cba53d85028fb97b1328696091b3b7ddd
Reviewed-on: https://go-review.googlesource.com/3600
Reviewed-by: Russ Cox <rsc@golang.org>
The overflow happens only with -gcflags="-N -l"
and can be reproduced with:
$ go test -gcflags="-N -l" -a -run=none net
runtime.cgocall: nosplit stack overflow
504 assumed on entry to runtime.cgocall
480 after runtime.cgocall uses 24
472 on entry to runtime.cgocall_errno
408 after runtime.cgocall_errno uses 64
400 on entry to runtime.exitsyscall
288 after runtime.exitsyscall uses 112
280 on entry to runtime.exitsyscallfast
152 after runtime.exitsyscallfast uses 128
144 on entry to runtime.writebarrierptr
88 after runtime.writebarrierptr uses 56
80 on entry to runtime.writebarrierptr_nostore1
24 after runtime.writebarrierptr_nostore1 uses 56
16 on entry to runtime.acquirem
-24 after runtime.acquirem uses 40
Move closure creation into separate function so that
frames of writebarrierptr_shadow and writebarrierptr_nostore1
are overlapped.
Fixes#9721
Change-Id: I40851f0786763ee964af34814edbc3e3d73cf4e7
Reviewed-on: https://go-review.googlesource.com/3418
Reviewed-by: Russ Cox <rsc@golang.org>
Currently race detector produces the following reports on pprof tests:
WARNING: DATA RACE
Read by goroutine 4:
runtime/pprof_test.TestTraceStartStop()
src/runtime/pprof/trace_test.go:38 +0x1da
testing.tRunner()
src/testing/testing.go:448 +0x13a
Previous write by goroutine 5:
bytes.(*Buffer).grow()
src/bytes/buffer.go:102 +0x190
bytes.(*Buffer).Write()
src/bytes/buffer.go:127 +0x75
runtime/pprof.func·002()
src/runtime/pprof/pprof.go:633 +0xae
Trace writer goroutine synchronizes with StopTrace
using trace.shutdownSema runtime semaphore.
But race detector does not see that synchronization
and so produces false reports.
Teach race detector about the synchronization.
Change-Id: I1219817325d4e16b423f29a0cbee94c929793881
Reviewed-on: https://go-review.googlesource.com/3746
Reviewed-by: Russ Cox <rsc@golang.org>
The test for the framepointer experiment flag is cheaper and more
branch-predictable than the other parts of this conditional, so move
it first. This is also more readable.
(Originally, the flag check required parsing the experiments string,
which is why it was done last. Now that flag is cached.)
Change-Id: I84e00fa7e939e9064f0fa0a4a6fe00576dd61457
Reviewed-on: https://go-review.googlesource.com/3782
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Previously, we checked for a saved frame pointer by looking for a
2*ptrSize gap between the argument pointer and the locals pointer.
The intent of this check was to look for a two stack slot gap (caller
IP and saved frame pointer), but stack slots are regSize, not ptrSize.
Correct this by checking instead for a 2*regSize gap.
On most platforms, this made no difference because ptrSize==regSize.
However, on amd64p32 (nacl), the saved frame pointer check incorrectly
fired when there was no saved frame pointer because the one stack slot
for the caller IP left an 8 byte gap, which is 2*ptrSize (but not
2*regSize) on amd64p32.
Fixes#9760.
Change-Id: I6eedcf681fe5bf2bf924dde8a8f2d9860a4d758e
Reviewed-on: https://go-review.googlesource.com/3781
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change adds support for case insensitivity of DNS labels to
built-in DNS stub resolver as described in RFC 4343.
Fixes#9215.
Change-Id: Ia752fe71866a3bfa3ea08371985b799d419ddea3
Reviewed-on: https://go-review.googlesource.com/3685
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fourth time's the charm.
Actually this doesn't fix the build, there is a
crash after go_bootstrap is compiled which looks
like it is related to auxv parsing.
Change-Id: Id00e2dfbe7bae42856f996065d3fb90b820e29a8
Reviewed-on: https://go-review.googlesource.com/3610
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add memprofrate as a value recognized in GODEBUG. The
value provided is used as the new setting for
runtime.MemProfileRate, allowing the user to
adjust memory profiling.
Change-Id: If129a247683263b11e2dd42473cf9b31280543d5
Reviewed-on: https://go-review.googlesource.com/3450
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fix one place where semicolons were not recognized and fix the
pattern match for the syntax of some pseudo ops.
Also clean up a couple of unreachable code pieces.
There is still an undiagnosed bit difference betwen old and new .6
files. TBD.
With these fixes, asm can successfully compile and test the entire tree.
(Verified by
turn off verifyAsm in cmd/go
make.bash
cp $GOROOT/bin/asm $GOROOT/pkg/tool/darwin_amd64/6a
go test -short std
)
Change-Id: I91ea892098f76ef4f129fd2530e0c63ffd8745a9
Reviewed-on: https://go-review.googlesource.com/3688
Reviewed-by: Russ Cox <rsc@golang.org>
This adds a "framepointer" GOEXPERIMENT that that makes the amd64
toolchain maintain base pointer chains in the same way that gcc
-fno-omit-frame-pointer does. Go doesn't use these saved base
pointers, but this does enable external tools like Linux perf and
VTune to unwind Go stacks when collecting system-wide profiles.
This requires support in the compilers to not clobber BP, support in
liblink for generating the BP-saving function prologue and unwinding
epilogue, and support in the runtime to save BPs across preemption, to
skip saved BPs during stack unwinding and, and to adjust saved BPs
during stack moving.
As with other GOEXPERIMENTs, everything from the toolchain to the
runtime must be compiled with this experiment enabled. To do this,
run make.bash (or all.bash) with GOEXPERIMENT=framepointer.
Change-Id: I4024853beefb9539949e5ca381adfdd9cfada544
Reviewed-on: https://go-review.googlesource.com/2992
Reviewed-by: Russ Cox <rsc@golang.org>
Any place that clobbers BP in the runtime can potentially interfere
with frame pointer unwinding with GOEXPERIMENT=framepointer. This
change eliminates uses of BP in the runtime to address this problem.
We have spare registers everywhere this occurs, so there's no downside
to eliminating BP. Where possible, this uses the same new register as
the amd64p32 runtime, which doesn't use BP due to restrictions placed
on it by NaCL.
One nice side effect of this is that it will let perf/VTune unwind the
call stack even through a call to systemstack, which will let us get
really good call graphs from the garbage collector.
Change-Id: I0ffa14cb4dd2b613a7049b8ec59df37c52286212
Reviewed-on: https://go-review.googlesource.com/3390
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
m.gcing has become overloaded to mean "don't preempt this g" in
general. Once the garbage collector is preemptible, the one thing it
*won't* mean is that we're in the garbage collector.
So, rename gcing to "preemptoff" and make it a string giving a reason
that preemption is disabled. gcing was never set to anything but 0 or
1, so we don't have to worry about there being a stack of reasons.
Change-Id: I4337c29e8e942e7aa4f106fc29597e1b5de4ef46
Reviewed-on: https://go-review.googlesource.com/3660
Reviewed-by: Russ Cox <rsc@golang.org>
Commit 656be31 replaced onM with systemstack, but missed updating a
few comments that still referred to onM. Update these.
Change-Id: I0efb017e9a66ea0adebb6e1da6e518ee11263f69
Reviewed-on: https://go-review.googlesource.com/3664
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
9g generates needlessly complex code for small copies. There are a
few other things that need to be improved about the copy code, so for
now just note the problem.
Change-Id: I0f1de4b2f9197a2635e27cc4b91ecf7a6c11f457
Reviewed-on: https://go-review.googlesource.com/3665
Reviewed-by: Russ Cox <rsc@golang.org>
In stripCommonPrefix, the prefix was correctly calculated in all cases,
except one. That unhandled case is when there are more than 2 lines,
but all lines are blank (other than the first and last lines,
which contain /* and */ respectively).
This change detects that case and correctly sets the prefix calculated
from the last line. This is consistent with the (correct) behavior
that happens when there's at least one non-blank line.
That fixes issue #9751 that occurs for problematic input,
where cmd/gofmt and go/source would insert extra indentation on
every format operation. It also allows go/printer itself to print
such parsed files in an expected way.
Fixes#9751.
Change-Id: Id3dfb945beb59ffad3705085a3c285fca30a5f87
Reviewed-on: https://go-review.googlesource.com/3684
Reviewed-by: Robert Griesemer <gri@golang.org>
Since CL 3676, the TestMkdirAllAtSlash test
depends on syscall.EROFS, which isn't defined
on Plan 9.
This change works around this issue by
defining a system dependent isReadonlyError
function.
Change-Id: If972fd2fe4828ee3bcb8537ea7f4ba29f7a87619
Reviewed-on: https://go-review.googlesource.com/3696
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is a followup to CL 3676.
Rather than silently returning from the test, a pass,
use the Skip facility to mark the test as skipped.
Change-Id: I90d237e770150bf8d69f14fb09874e70894a7f86
Reviewed-on: https://go-review.googlesource.com/3682
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
On some systems (e.g. ChromeOS), / is mounted read-only.
This results in error code syscall.EROFS, which I guess
is just as valid as syscall.EACCES for this test.
Change-Id: I9188d5437a1b5ac1daa9c68b95b8dcb447666ca3
Reviewed-on: https://go-review.googlesource.com/3676
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Given
#define X() foo
X()
X
cpp produces
foo
X
Asm does now as well.
Change-Id: Ia36b88a23ce1660e6a02559c4f730593d62066f1
Reviewed-on: https://go-review.googlesource.com/3611
Reviewed-by: Russ Cox <rsc@golang.org>
The previous one was too broken, so just rewrite the code that invokes
a macro. Basically it was evaluating things too early, and mishandling
nested invocations. It's also easier to understand now.
Keep backslash-newline around in macro definitions. They get
processed when the body is evaluated.
Write some golden tests.
Change-Id: I27435f77f258a0873f80932bdc8d13ad39821ac1
Reviewed-on: https://go-review.googlesource.com/3550
Reviewed-by: Russ Cox <rsc@golang.org>
Another attempt to fix the arm build by moving the include of signal.h
to cmd/lex.c, unless we are building on plan9.
Obviously if we had a plan9/arm builder this would probably not work, but
this is only a temporary measure until the c2go transition is complete.
Change-Id: I7f8ae27349b2e7a09c55db03e02a01939159a268
Reviewed-on: https://go-review.googlesource.com/3566
Reviewed-by: Russ Cox <rsc@golang.org>
The following line in sysFree:
n += (n + memRound) &^ memRound
doubles value of n (n += n).
Which is wrong and can lead to memory corruption.
Fixes#9712
Change-Id: I3c141b71da11e38837c09408cf4f1d22e8f7f36e
Reviewed-on: https://go-review.googlesource.com/3602
Reviewed-by: David du Colombier <0intro@gmail.com>
REG_R0 etc are defined in <ucontext.h> on ARM systems.
Possible use of uninitialized n in 8g/reg.c.
Change-Id: I6e8ce83a6515ca2b779ed8a344a25432db629cc2
Reviewed-on: https://go-review.googlesource.com/3578
Reviewed-by: Russ Cox <rsc@golang.org>
headstr(Hlinux) was reporting "android",
making for some confusing error messages.
Change-Id: I437095bee7cb2143aa37c91cf786f3a3581ae7b9
Reviewed-on: https://go-review.googlesource.com/3513
Reviewed-by: Austin Clements <austin@google.com>
In addition to duplicating the logic, the old code was
clearing the line number, which led to missing source line
information in the -S output.
Also fix nopout, which was incomplete.
Change-Id: Ic2b596a2f9ec2fe85642ebe125cca8ef38c83085
Reviewed-on: https://go-review.googlesource.com/3512
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Dave Cheney <dave@cheney.net>
- certain code paths were appending to the string without first clearing it.
- some prints were using spaces instead of tabs
Change-Id: I7a3d38289c8206682baf8942abf5a9950a56b449
Reviewed-on: https://go-review.googlesource.com/3511
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Dave Cheney <dave@cheney.net>
The overflow checking was causing more problems than it was avoiding,
so get rid of it. But because arithmetic is done with uint64s, to simplify
dealing with large constants, complain about right shift and divide with
huge numbers to avoid ambiguity about signed shifts.
Change-Id: I5b5ea55d8e8c02846605f4a3f8fd7a176b1e962b
Reviewed-on: https://go-review.googlesource.com/3531
Reviewed-by: Russ Cox <rsc@golang.org>
Set gcscanvalid=false after you have cased to _Grunning.
If you do it before the cas and the atomicstatus races to a scan state,
the scan will set gcscanvalid=true and we will be _Grunning
with gcscanvalid==true which is not a good thing.
Change-Id: Ie53ea744a5600392b47da91159d985fe6fe75961
Reviewed-on: https://go-review.googlesource.com/3510
Reviewed-by: Austin Clements <austin@google.com>
Yet another leftover from C: parfor took a func value for the
callback, casted it to an unsafe.Pointer for storage, and then casted
it back to a func value to call it. This is unnecessary, so just
store the body as a func value. Beyond general cleanup, this also
eliminates the last use of unsafe in parfor.
Change-Id: Ia904af7c6c443ba75e2699835aee8e9a39b26dd8
Reviewed-on: https://go-review.googlesource.com/3396
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Prior to the conversion of the runtime to Go, this void* was
necessary to get closure information in to C callbacks. There
are no more C callbacks and parfor is perfectly capable of
invoking a Go closure now, so eliminate ctx and all of its
unsafe-ness. (Plus, the runtime currently doesn't use ctx for
anything.)
Change-Id: I39fc53b7dd3d7f660710abc76b0d831bfc6296d8
Reviewed-on: https://go-review.googlesource.com/3395
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
parfor originally used a tail array for its thread array. This got
replaced with a slice allocation in the conversion to Go, but many of
its gnarlier effects remained. Instead of keeping track of the
pointer to the first element of the slice and using unsafe pointer
math to get at the ith element, just keep the slice around and use
regular slice indexing. There is no longer any need for padding to
64-bit align the tail array (there hasn't been since the Go
conversion), so remove this unnecessary padding from the parfor
struct. Finally, since the slice tracks its own length, replace the
nthrmax field with len(thr).
Change-Id: I0020a1815849bca53e3613a8fa46ae4fbae67576
Reviewed-on: https://go-review.googlesource.com/3394
Reviewed-by: Russ Cox <rsc@golang.org>
This cleanup was slated for after the conversion of the runtime to Go.
Also improve type and function documentation.
Change-Id: I55a16b09e00cf701f246deb69e7ce7e3e04b26e7
Reviewed-on: https://go-review.googlesource.com/3393
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Currently, if we do an atomic{load,store}64 of an unaligned address on
386, we'll simply get a non-atomic load/store. This has been the
source of myriad bugs, so add alignment checks to these two
operations. These checks parallel the equivalent checks in
sync/atomic.
The alignment check is not necessary in cas64 because it uses a locked
instruction. The CPU will either execute this atomically or raise an
alignment fault (#AC)---depending on the alignment check flag---either
of which is fine.
This also fixes the two places in the runtime that trip the new
checks. One is in the runtime self-test and shouldn't have caused
real problems. The other is in tickspersecond and could, in
principle, have caused a misread of the ticks per second during
initialization.
Change-Id: If1796667012a6154f64f5e71d043c7f5fb3dd050
Reviewed-on: https://go-review.googlesource.com/3521
Reviewed-by: Russ Cox <rsc@golang.org>
Like the -exec flag, which specifies a program to use to run a built executable,
the -toolexec flag specifies a program to use to run a tool like 5a, 5g, or 5l.
This flag enables running the toolchain under common testing environments,
such as valgrind.
This flag also enables the use of custom testing environments or the substitution
of alternate tools. See https://godoc.org/rsc.io/toolstash for one possibility.
Change-Id: I256aa7af2d96a4bc7911dc58151cc2155dbd4121
Reviewed-on: https://go-review.googlesource.com/3351
Reviewed-by: Rob Pike <r@golang.org>
Language specification says that variables are captured by reference.
And that is what gc compiler does. However, in lots of cases it is
possible to capture variables by value under the hood without
affecting visible behavior of programs. For example, consider
the following typical pattern:
func (o *Obj) requestMany(urls []string) []Result {
wg := new(sync.WaitGroup)
wg.Add(len(urls))
res := make([]Result, len(urls))
for i := range urls {
i := i
go func() {
res[i] = o.requestOne(urls[i])
wg.Done()
}()
}
wg.Wait()
return res
}
Currently o, wg, res, and i are captured by reference causing 3+len(urls)
allocations (e.g. PPARAM o is promoted to PPARAMREF and moved to heap).
But all of them can be captured by value without changing behavior.
This change implements simple strategy for capturing by value:
if a captured variable is not addrtaken and never assigned to,
then it is captured by value (it is effectively const).
This simple strategy turned out to be very effective:
~80% of all captures in std lib are turned into value captures.
The remaining 20% are mostly in defers and non-escaping closures,
that is, they do not cause allocations anyway.
benchmark old allocs new allocs delta
BenchmarkCompressedZipGarbage 153 126 -17.65%
BenchmarkEncodeDigitsSpeed1e4 91 69 -24.18%
BenchmarkEncodeDigitsSpeed1e5 178 129 -27.53%
BenchmarkEncodeDigitsSpeed1e6 1510 1051 -30.40%
BenchmarkEncodeDigitsDefault1e4 100 75 -25.00%
BenchmarkEncodeDigitsDefault1e5 193 139 -27.98%
BenchmarkEncodeDigitsDefault1e6 1420 985 -30.63%
BenchmarkEncodeDigitsCompress1e4 100 75 -25.00%
BenchmarkEncodeDigitsCompress1e5 193 139 -27.98%
BenchmarkEncodeDigitsCompress1e6 1420 985 -30.63%
BenchmarkEncodeTwainSpeed1e4 109 81 -25.69%
BenchmarkEncodeTwainSpeed1e5 211 151 -28.44%
BenchmarkEncodeTwainSpeed1e6 1588 1097 -30.92%
BenchmarkEncodeTwainDefault1e4 103 77 -25.24%
BenchmarkEncodeTwainDefault1e5 199 143 -28.14%
BenchmarkEncodeTwainDefault1e6 1324 917 -30.74%
BenchmarkEncodeTwainCompress1e4 103 77 -25.24%
BenchmarkEncodeTwainCompress1e5 190 137 -27.89%
BenchmarkEncodeTwainCompress1e6 1327 919 -30.75%
BenchmarkConcurrentDBExec 16223 16220 -0.02%
BenchmarkConcurrentStmtQuery 17687 16182 -8.51%
BenchmarkConcurrentStmtExec 5191 5186 -0.10%
BenchmarkConcurrentTxQuery 17665 17661 -0.02%
BenchmarkConcurrentTxExec 15154 15150 -0.03%
BenchmarkConcurrentTxStmtQuery 17661 16157 -8.52%
BenchmarkConcurrentTxStmtExec 3677 3673 -0.11%
BenchmarkConcurrentRandom 14000 13614 -2.76%
BenchmarkManyConcurrentQueries 25 22 -12.00%
BenchmarkDecodeComplex128Slice 318 252 -20.75%
BenchmarkDecodeFloat64Slice 318 252 -20.75%
BenchmarkDecodeInt32Slice 318 252 -20.75%
BenchmarkDecodeStringSlice 2318 2252 -2.85%
BenchmarkDecode 11 8 -27.27%
BenchmarkEncodeGray 64 56 -12.50%
BenchmarkEncodeNRGBOpaque 64 56 -12.50%
BenchmarkEncodeNRGBA 67 58 -13.43%
BenchmarkEncodePaletted 68 60 -11.76%
BenchmarkEncodeRGBOpaque 64 56 -12.50%
BenchmarkGoLookupIP 153 139 -9.15%
BenchmarkGoLookupIPNoSuchHost 508 466 -8.27%
BenchmarkGoLookupIPWithBrokenNameServer 245 226 -7.76%
BenchmarkClientServer 62 59 -4.84%
BenchmarkClientServerParallel4 62 59 -4.84%
BenchmarkClientServerParallel64 62 59 -4.84%
BenchmarkClientServerParallelTLS4 79 76 -3.80%
BenchmarkClientServerParallelTLS64 112 109 -2.68%
BenchmarkCreateGoroutinesCapture 10 6 -40.00%
BenchmarkAfterFunc 1006 1005 -0.10%
Fixes#6632.
Change-Id: I0cd51e4d356331d7f3c5f447669080cd19b0d2ca
Reviewed-on: https://go-review.googlesource.com/3166
Reviewed-by: Russ Cox <rsc@golang.org>
A few packages that handle net.IPConn in golang.org/x/net sub repository
already implement full stack test cases with more coverage than the net
package. There is no need to keep duplicate code around here.
This change removes full stack test cases for IPConn that require
knowing how to speak with each of protocol stack implementation of
supported platforms.
Change-Id: I871119a9746fc6a2b997b69cfd733463558f5816
Reviewed-on: https://go-review.googlesource.com/3404
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For now solaris port does not support cgo. Moreover, its system calls
and library interfaces are different from BSD.
Change-Id: Idb4fed889973368b35d38b361b23581abacfdeab
Reviewed-on: https://go-review.googlesource.com/3306
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Using a mutex to protect a single int operation is quite heavyweight.
Using sync/atomic provides much better performance. This change was
benchmarked as such:
BenchmarkSync 10000000 139 ns/op
BenchmarkAtomic 200000000 9.90 ns/op
package blah
import (
"sync"
"sync/atomic"
"testing"
)
type Int struct {
mu sync.RWMutex
i int64
}
func (v *Int) Add(delta int64) {
v.mu.Lock()
defer v.mu.Unlock()
v.i += delta
}
type AtomicInt struct {
i int64
}
func (v *AtomicInt) Add(delta int64) {
atomic.AddInt64(&v.i, delta)
}
func BenchmarkSync(b *testing.B) {
s := new(Int)
for i := 0; i < b.N; i++ {
s.Add(1)
}
}
func BenchmarkAtomic(b *testing.B) {
s := new(AtomicInt)
for i := 0; i < b.N; i++ {
s.Add(1)
}
}
Change-Id: I6998239c785967647351bbfe8533c38e4894543b
Reviewed-on: https://go-review.googlesource.com/3430
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
This patch was previously sent for review using hg:
golang.org/cl/173930043
Change-Id: I559a2f2ee07990d0c23d2580381e32f8e23077a5
Reviewed-on: https://go-review.googlesource.com/3033
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also:
- use io.ByteScanner rather than io.RuneScanner internally
- minor simplifications in Float.Add/Sub
Change-Id: Iae0e99384128dba9eccf68592c4fd389e2bd3b4f
Reviewed-on: https://go-review.googlesource.com/3380
Reviewed-by: Rob Pike <r@golang.org>
The internal size of integers is not part of the definition of the assembler,
so if bits roll out the top it's a portability problem at best.
If you need to use shift to create a mask, use & to restrict the bit count
before shifting. That will make it portable, too.
Change-Id: I24f9a4d2152c3f9f253e22ff75270fe50c18612b
Reviewed-on: https://go-review.googlesource.com/3451
Reviewed-by: Russ Cox <rsc@golang.org>
Set the minimum heap size to 4Mbytes except when the hash
table code wants to force a GC. In an unrelated change when a
mutator is asked to assist the GC by marking pointer workbufs
it will keep working until the requested number of pointers
are processed even if it means asking for additional workbufs.
Change-Id: I661cfc0a7f2efcf6286b5d37d73e593d9ecd04d5
Reviewed-on: https://go-review.googlesource.com/3392
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Rewrite the grammar to have one more production so it parses
~0*0
correctly and write tests to prove it.
Change-Id: I0dd652baf65b48a3f26c9287c420702db4eaec59
Reviewed-on: https://go-review.googlesource.com/3443
Reviewed-by: Russ Cox <rsc@golang.org>
If result of string(i) does not escape,
allocate a [4]byte temp on stack for it.
Change-Id: If31ce9447982929d5b3b963fd0830efae4247c37
Reviewed-on: https://go-review.googlesource.com/3411
Reviewed-by: Russ Cox <rsc@golang.org>
Allow TEXT to have two or three operands.
In
TEXT foo(SB),flag,$0
the flag can be missing, in which case we take it to be zero.
Change-Id: I7b88543b52019f7890baac4b95f9e63884d43c83
Reviewed-on: https://go-review.googlesource.com/3440
Reviewed-by: Russ Cox <rsc@golang.org>
Currently we always allocate string buffers in heap.
For example, in the following code we allocate a temp string
just for comparison:
if string(byteSlice) == "abc" { ... }
This change extends escape analysis to cover []byte->string
conversions and string concatenation. If the result of operations
does not escape, compiler allocates a small buffer
on stack and passes it to slicebytetostring and concatstrings.
Then runtime uses the buffer if the result fits into it.
Size of the buffer is 32 bytes. There is no fundamental theory
behind this number. Just an observation that on std lib
tests/benchmarks frequency of string allocation is inversely
proportional to string length; and there is significant number
of allocations up to length 32.
benchmark old allocs new allocs delta
BenchmarkFprintfBytes 2 1 -50.00%
BenchmarkDecodeComplex128Slice 318 316 -0.63%
BenchmarkDecodeFloat64Slice 318 316 -0.63%
BenchmarkDecodeInt32Slice 318 316 -0.63%
BenchmarkDecodeStringSlice 2318 2316 -0.09%
BenchmarkStripTags 11 5 -54.55%
BenchmarkDecodeGray 111 102 -8.11%
BenchmarkDecodeNRGBAGradient 200 188 -6.00%
BenchmarkDecodeNRGBAOpaque 165 152 -7.88%
BenchmarkDecodePaletted 319 309 -3.13%
BenchmarkDecodeRGB 166 157 -5.42%
BenchmarkDecodeInterlacing 279 268 -3.94%
BenchmarkGoLookupIP 153 135 -11.76%
BenchmarkGoLookupIPNoSuchHost 508 466 -8.27%
BenchmarkGoLookupIPWithBrokenNameServer 245 226 -7.76%
BenchmarkClientServerParallel4 62 61 -1.61%
BenchmarkClientServerParallel64 62 61 -1.61%
BenchmarkClientServerParallelTLS4 79 78 -1.27%
BenchmarkClientServerParallelTLS64 112 111 -0.89%
benchmark old ns/op new ns/op delta
BenchmarkFprintfBytes 381 311 -18.37%
BenchmarkStripTags 2615 2351 -10.10%
BenchmarkDecodeNRGBAGradient 3715887 3635096 -2.17%
BenchmarkDecodeNRGBAOpaque 3047645 2928644 -3.90%
BenchmarkGoLookupIP 153 135 -11.76%
BenchmarkGoLookupIPNoSuchHost 508 466 -8.27%
Change-Id: I9ec01da816945c3329d7be3c7794b520418c3f99
Reviewed-on: https://go-review.googlesource.com/3120
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
During a concurrent GC stacks are scanned in
an initial scan phase informing the GC of all
pointers on the stack. The GC only needs to rescan
the stack if it potentially changes which can only
happen if the goroutine runs.
This CL tracks whether the Goroutine has run
since it was last scanned and thus may have changed
its stack. If necessary the stack is rescanned.
Change-Id: I5fb1c4338d42e3f61ab56c9beb63b7b2da25f4f1
Reviewed-on: https://go-review.googlesource.com/3275
Reviewed-by: Russ Cox <rsc@golang.org>
Currently we allocate a new string during []byte->string conversion
in string comparison expressions. String allocation is unnecessary in
this case, because comparison does memorize the strings for later use.
This change uses slicebytetostringtmp to construct temp string directly
from []byte buffer and passes it to runtime.eqstring.
Change-Id: If00f1faaee2076baa6f6724d245d5b5e0f59b563
Reviewed-on: https://go-review.googlesource.com/3410
Reviewed-by: Russ Cox <rsc@golang.org>
Coarse-grained test skips to fix bots.
Need to look closer at windows and nacl failures.
Change-Id: I767ef1707232918636b33f715459ee3c0349b45e
Reviewed-on: https://go-review.googlesource.com/3416
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It was too complicated, assuming the syntax is more general than reality.
It must be a possibly negative integer followed by an optional minus sign
and positive integer. Literals only, no expresssions.
Also put in a TODO about address parsing and clean up a couple of types.
Change-Id: If8652249c742e42771ccf2e3024f77307b2e5d9a
Reviewed-on: https://go-review.googlesource.com/3370
Reviewed-by: Russ Cox <rsc@golang.org>
Escape analysis treats everything assigned to OIND/ODOTPTR as escaping.
As the result b escapes in the following code:
func (b *Buffer) Foo() {
n, m := ...
b.buf = b.buf[n:m]
}
This change recognizes such assignments and ignores them.
Update issue #9043.
Update issue #7921.
There are two similar cases in std lib that benefit from this optimization.
First is in archive/zip:
type readBuf []byte
func (b *readBuf) uint32() uint32 {
v := binary.LittleEndian.Uint32(*b)
*b = (*b)[4:]
return v
}
Second is in time:
type data struct {
p []byte
error bool
}
func (d *data) read(n int) []byte {
if len(d.p) < n {
d.p = nil
d.error = true
return nil
}
p := d.p[0:n]
d.p = d.p[n:]
return p
}
benchmark old ns/op new ns/op delta
BenchmarkCompressedZipGarbage 32431724 32217851 -0.66%
benchmark old allocs new allocs delta
BenchmarkCompressedZipGarbage 153 143 -6.54%
Change-Id: Ia6cd32744e02e36d6d8c19f402f8451101711626
Reviewed-on: https://go-review.googlesource.com/3162
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Currently all PTRLIT element initializers escape. There is no reason for that.
This change links STRUCTLIT to PTRLIT; STRUCTLIT element initializers are
already linked to the STRUCTLIT. As the result, PTRLIT element initializers
escape when PTRLIT itself escapes.
Change-Id: I89ecd8677cbf81addcfd469cd2fd461c0e9bf7dd
Reviewed-on: https://go-review.googlesource.com/3031
Reviewed-by: Russ Cox <rsc@golang.org>
For some reason the current conditions require the type to be "uintptr-shaped".
This cuts off structs and arrays with a pointer.
isdirectiface and width==widthptr is sufficient condition to enable the fast paths.
Change-Id: I11842531e7941365413606cfd6c34c202aa14786
Reviewed-on: https://go-review.googlesource.com/3414
Reviewed-by: Russ Cox <rsc@golang.org>
Call frame allocations can account for significant portion
of all allocations in a program, if call is executed
in an inner loop (e.g. to process every line in a log).
On the other hand, the allocation is easy to remove
using sync.Pool since the allocation is strictly scoped.
benchmark old ns/op new ns/op delta
BenchmarkCall 634 338 -46.69%
BenchmarkCall-4 496 167 -66.33%
benchmark old allocs new allocs delta
BenchmarkCall 1 0 -100.00%
BenchmarkCall-4 1 0 -100.00%
Update #7818
Change-Id: Icf60cce0a9be82e6171f0c0bd80dee2393db54a7
Reviewed-on: https://go-review.googlesource.com/1954
Reviewed-by: Keith Randall <khr@golang.org>
This change extends existing test case to Windows for helping to fix
golang.org/issue/5395.
Change-Id: Iff077fa98ede511981df513f48d84c19375b3e04
Reviewed-on: https://go-review.googlesource.com/3304
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Pointers change from run to run, making it hard to use
the debug output to identify the reason for a changed
object file.
Change-Id: I0c954da0943092c48686afc99ecf75eba516de6a
Reviewed-on: https://go-review.googlesource.com/3352
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: Rob Pike <r@golang.org>
ECDSA is unsafe to use if an entropy source produces predictable
output for the ephemeral nonces. E.g., [Nguyen]. A simple
countermeasure is to hash the secret key, the message, and
entropy together to seed a CSPRNG, from which the ephemeral key
is derived.
Fixes#9452
--
This is a minimalist (in terms of patch size) solution, though
not the most parsimonious in its use of primitives:
- csprng_key = ChopMD-256(SHA2-512(priv.D||entropy||hash))
- reader = AES-256-CTR(k=csprng_key)
This, however, provides at most 128-bit collision-resistance,
so that Adv will have a term related to the number of messages
signed that is significantly worse than plain ECDSA. This does
not seem to be of any practical importance.
ChopMD-256(SHA2-512(x)) is used, rather than SHA2-256(x), for
two sets of reasons:
*Practical:* SHA2-512 has a larger state and 16 more rounds; it
is likely non-generically stronger than SHA2-256. And, AFAIK,
cryptanalysis backs this up. (E.g., [Biryukov] gives a
distinguisher on 47-round SHA2-256 with cost < 2^85.) This is
well below a reasonable security-strength target.
*Theoretical:* [Coron] and [Chang] show that Chop-MD(F(x)) is
indifferentiable from a random oracle for slightly beyond the
birthday barrier. It seems likely that this makes a generic
security proof that this construction remains UF-CMA is
possible in the indifferentiability framework.
--
Many thanks to Payman Mohassel for reviewing this construction;
any mistakes are mine, however. And, as he notes, reusing the
private key in this way means that the generic-group (non-RO)
proof of ECDSA's security given in [Brown] no longer directly
applies.
--
[Brown]: http://www.cacr.math.uwaterloo.ca/techreports/2000/corr2000-54.ps
"Brown. The exact security of ECDSA. 2000"
[Coron]: https://www.cs.nyu.edu/~puniya/papers/merkle.pdf
"Coron et al. Merkle-Damgard revisited. 2005"
[Chang]: https://www.iacr.org/archive/fse2008/50860436/50860436.pdf
"Chang and Nandi. Improved indifferentiability security analysis
of chopMD hash function. 2008"
[Biryukov]: http://www.iacr.org/archive/asiacrypt2011/70730269/70730269.pdf
"Biryukov et al. Second-order differential collisions for reduced
SHA-256. 2011"
[Nguyen]: ftp://ftp.di.ens.fr/pub/users/pnguyen/PubECDSA.ps
"Nguyen and Shparlinski. The insecurity of the elliptic curve
digital signature algorithm with partially known nonces. 2003"
New tests:
TestNonceSafety: Check that signatures are safe even with a
broken entropy source.
TestINDCCA: Check that signatures remain non-deterministic
with a functional entropy source.
Updated "golden" KATs in crypto/tls/testdata that use ECDSA suites.
Change-Id: I55337a2fbec2e42a36ce719bd2184793682d678a
Reviewed-on: https://go-review.googlesource.com/3340
Reviewed-by: Adam Langley <agl@golang.org>
The %61 hack was added when runtime was is in C.
Now the Go compiler does the optimization.
Change-Id: I79c3302ec4b931eaaaaffe75e7101c92bf287fc7
Reviewed-on: https://go-review.googlesource.com/3289
Reviewed-by: Keith Randall <khr@golang.org>
BenchmarkClient is intended for profiling
the client without the HTTP server code.
The server code runs in a subprocess.
Change-Id: I9aa128604d0d4e94dc5c0372dc86f962282ed6e8
Reviewed-on: https://go-review.googlesource.com/3164
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Consider the following code:
s := "(" + string(byteSlice) + ")"
Currently we allocate a new string during []byte->string conversion,
and pass it to concatstrings. String allocation is unnecessary in
this case, because concatstrings does memorize the strings for later use.
This change uses slicebytetostringtmp to construct temp string directly
from []byte buffer and passes it to concatstrings.
I've found few such cases in std lib:
s += string(msg[off:off+c]) + "."
buf.WriteString("Sec-WebSocket-Accept: " + string(c.accept) + "\r\n")
bw.WriteString("Sec-WebSocket-Key: " + string(nonce) + "\r\n")
err = xml.Unmarshal([]byte("<Top>"+string(data)+"</Top>"), &logStruct)
d.err = d.syntaxError("invalid XML name: " + string(b))
return m, ProtocolError("malformed MIME header line: " + string(kv))
But there are much more in our internal code base.
Change-Id: I42f401f317131237ddd0cb9786b0940213af16fb
Reviewed-on: https://go-review.googlesource.com/3163
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This is another case where we can say that the address refers to stack.
We create such temps for OSTRUCTLIT initialization.
This eliminates a handful of write barriers today.
But this come up a prerequisite for another change (capturing vars by value),
otherwise we emit writebarriers in writebarrier itself when
capture writebarrier arguments by value.
Change-Id: Ibba93acd0f5431c5a4c3d90ef1e622cb9a7ff50e
Reviewed-on: https://go-review.googlesource.com/3285
Reviewed-by: Russ Cox <rsc@golang.org>
Typecheck for range variables before typechecking for range body.
Body can refer to new vars declared in for range,
so it is preferable to typecheck them before the body.
Makes typecheck order consistent between ORANGE and OFOR.
This come up during another change that computes some predicates
on variables during typechecking.
Change-Id: Ic975db61b1fd5b7f9ee78896d4cc7d93c593c532
Reviewed-on: https://go-review.googlesource.com/3284
Reviewed-by: Russ Cox <rsc@golang.org>
Half of tests currently crash with GODEBUG=wbshadow.
_PageSize is set to 8192. So data can be extended outside
of actually mapped region during rounding. Which leads to crash
during initial copying to shadow.
Use _PhysPageSize instead.
Change-Id: Iaa89992bd57f86dafa16b092b53fdc0606213acb
Reviewed-on: https://go-review.googlesource.com/3286
Reviewed-by: Russ Cox <rsc@golang.org>
Currently we scan maps even if k/v does not contain pointers.
This is required because overflow buckets are hanging off the main table.
This change introduces a separate array that contains pointers to all
overflow buckets and keeps them alive. Buckets themselves are marked
as containing no pointers and are not scanned by GC (if k/v does not
contain pointers).
This brings maps in line with slices and chans -- GC does not scan
their contents if elements do not contain pointers.
Currently scanning of a map[int]int with 2e8 entries (~8GB heap)
takes ~8 seconds. With this change scanning takes negligible time.
Update #9477.
Change-Id: Id8a04066a53d2f743474cad406afb9f30f00eaae
Reviewed-on: https://go-review.googlesource.com/3288
Reviewed-by: Keith Randall <khr@golang.org>
ECDSA is unsafe to use if an entropy source produces predictable
output for the ephemeral nonces. E.g., [Nguyen]. A simple
countermeasure is to hash the secret key, the message, and
entropy together to seed a CSPRNG, from which the ephemeral key
is derived.
--
This is a minimalist (in terms of patch size) solution, though
not the most parsimonious in its use of primitives:
- csprng_key = ChopMD-256(SHA2-512(priv.D||entropy||hash))
- reader = AES-256-CTR(k=csprng_key)
This, however, provides at most 128-bit collision-resistance,
so that Adv will have a term related to the number of messages
signed that is significantly worse than plain ECDSA. This does
not seem to be of any practical importance.
ChopMD-256(SHA2-512(x)) is used, rather than SHA2-256(x), for
two sets of reasons:
*Practical:* SHA2-512 has a larger state and 16 more rounds; it
is likely non-generically stronger than SHA2-256. And, AFAIK,
cryptanalysis backs this up. (E.g., [Biryukov] gives a
distinguisher on 47-round SHA2-256 with cost < 2^85.) This is
well below a reasonable security-strength target.
*Theoretical:* [Coron] and [Chang] show that Chop-MD(F(x)) is
indifferentiable from a random oracle for slightly beyond the
birthday barrier. It seems likely that this makes a generic
security proof that this construction remains UF-CMA is
possible in the indifferentiability framework.
--
Many thanks to Payman Mohassel for reviewing this construction;
any mistakes are mine, however. And, as he notes, reusing the
private key in this way means that the generic-group (non-RO)
proof of ECDSA's security given in [Brown] no longer directly
applies.
--
[Brown]: http://www.cacr.math.uwaterloo.ca/techreports/2000/corr2000-54.ps
"Brown. The exact security of ECDSA. 2000"
[Coron]: https://www.cs.nyu.edu/~puniya/papers/merkle.pdf
"Coron et al. Merkle-Damgard revisited. 2005"
[Chang]: https://www.iacr.org/archive/fse2008/50860436/50860436.pdf
"Chang and Nandi. Improved indifferentiability security analysis
of chopMD hash function. 2008"
[Biryukov]: http://www.iacr.org/archive/asiacrypt2011/70730269/70730269.pdf
"Biryukov et al. Second-order differential collisions for reduced
SHA-256. 2011"
[Nguyen]: ftp://ftp.di.ens.fr/pub/users/pnguyen/PubECDSA.ps
"Nguyen and Shparlinski. The insecurity of the elliptic curve
digital signature algorithm with partially known nonces. 2003"
Fixes#9452
Tests:
TestNonceSafety: Check that signatures are safe even with a
broken entropy source.
TestINDCCA: Check that signatures remain non-deterministic
with a functional entropy source.
Change-Id: Ie7e04057a3a26e6becb80e845ecb5004bb482745
Reviewed-on: https://go-review.googlesource.com/2422
Reviewed-by: Adam Langley <agl@golang.org>
The argument is unused in the C code but will be used in the Go translation,
because the Prog holds information needed to invoke the right meaning
of %A in the ctxt->diag calls in vaddr.
Change-Id: I501830f8ea0e909aafd8ec9ef5d7338e109d9548
Reviewed-on: https://go-review.googlesource.com/3041
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/3310
Reviewed-by: Russ Cox <rsc@golang.org>
- Remove more ? : expressions.
- Use uint32 **hash instead of uint32 *hash[] in function argument.
- Change array.c API to use int, not int32, to match Go's slices.
- Rename strlit to newstrlit, to avoid case-insensitive collision with Strlit.
- Fix a few incorrect printf formats.
- Rename a few variables from 'len' to n or length.
- Eliminate direct string editing building up names like convI2T.
Change-Id: I754cf553402ccdd4963e51b7039f589286219c29
Reviewed-on: https://go-review.googlesource.com/3278
Reviewed-by: Rob Pike <r@golang.org>
cmd/gc contains symbol references into the back end dirs like 6g.
It also contains a few files that include the back end header files and
are compiled separately for each back end, despite being in cmd/gc.
cmd/gc also defines main, which makes at least one reverse symbol
reference unavoidable. (Otherwise you can't get into back-end code.)
This was all expedient, but it's too tightly coupled, especially for a
program written Go.
Make cmd/gc into a true library, letting the back end define main and
call into cmd/gc after making the necessary references available.
cmd/gc being a real library will ease the transition to Go.
Change-Id: I4fb9a0e2b11a32f1d024b3c56fc3bd9ee458842c
Reviewed-on: https://go-review.googlesource.com/3277
Reviewed-by: Rob Pike <r@golang.org>
- Change forward reference to struct Node* to void* in liblink.
- Use explicit (Node*) casts in cmd/gc to get at that field.
- Define struct Array in go.h instead of hiding it in array.c.
- Remove some sizeof(uint32), sizeof(uint64) uses.
- Remove some ? : expressions.
- Rewrite some problematic mid-expression assignments.
Change-Id: I308c70140238a0cfffd90e133f86f442cd0e17d4
Reviewed-on: https://go-review.googlesource.com/3276
Reviewed-by: Rob Pike <r@golang.org>
This change is a recreation of the CL written
by Nick Owens on http://golang.org/cl/150730043.
If the stat buffer is too short, the kernel
informs us by putting the 2-byte size in the
buffer, so we read that and try again.
This follows the same algorithm as /sys/src/libc/9sys/dirfstat.c.
Fixes#8781.
Change-Id: I01b4ad3a5e705dd4cab6673c7a119f8bef9bbd7c
Reviewed-on: https://go-review.googlesource.com/3281
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Creating a tar containing files with 0000 permission bits is
not going to be useful.
Change-Id: Ie489c2891c335d32270b18f37b0e32ecdca536a6
Reviewed-on: https://go-review.googlesource.com/3271
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Previouslly, Stmt.connStmt calls DB.connIfFree on each Stmt.css.
Since Stmt.connStmt locks Stmt.mu, a concurrent use of Stmt causes lock
contention on Stmt.mu.
Additionally, DB.connIfFree locks DB.mu which is shared by DB.addDep and
DB.removeDep.
This change removes DB.connIfFree and makes use of a first unused
connection in idle connection pool to reduce lock contention
without making it complicated.
Fixes#9484
On EC2 c3.8xlarge (E5-2680 v2 @ 2.80GHz * 32 vCPU):
benchmark old ns/op new ns/op delta
BenchmarkManyConcurrentQuery-8 40249 34721 -13.73%
BenchmarkManyConcurrentQuery-16 45610 40176 -11.91%
BenchmarkManyConcurrentQuery-32 109831 43179 -60.69%
benchmark old allocs new allocs delta
BenchmarkManyConcurrentQuery-8 25 25 +0.00%
BenchmarkManyConcurrentQuery-16 25 25 +0.00%
BenchmarkManyConcurrentQuery-32 25 25 +0.00%
benchmark old bytes new bytes delta
BenchmarkManyConcurrentQuery-8 3980 3969 -0.28%
BenchmarkManyConcurrentQuery-16 3980 3982 +0.05%
BenchmarkManyConcurrentQuery-32 3993 3990 -0.08%
Change-Id: Ic96296922c465bac38a260018c58324dae1531d9
Reviewed-on: https://go-review.googlesource.com/2207
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Implemented:
- +, -, *, /, and some unary ops
- all rounding modes
- basic conversions
- string to float conversion
- tests
Missing:
- float to string conversion, formatting
- handling of +/-0 and +/-inf (under- and overflow)
- various TODOs and cleanups
With precision set to 24 or 53, the results match
float32 or float64 operations exactly (excluding
NaNs and denormalized numbers which will not be
supported).
Change-Id: I3121e90fc4b1528e40bb6ff526008da18b3c6520
Reviewed-on: https://go-review.googlesource.com/1218
Reviewed-by: Alan Donovan <adonovan@google.com>
Fix up a couple of minor things pointed out in the last review.
Also:
1. If the symbol starts with center dot, prefix the name with "".
2. If there is no locals size specified, use ArgsSizeUnknown (sic).
3. Do not emit a history point at the start of a macro invocation,
since we do not pop it at the end, behavior consistent with the
old code.
With these changes, old and new assemblers produce identical
output at least for my simple test case, so that provides a verifiable
check for future cleanups.
Change-Id: Iaa91d8e453109824b4be44321ec5e828f39f0299
Reviewed-on: https://go-review.googlesource.com/3242
Reviewed-by: Russ Cox <rsc@golang.org>
Add main.go, the simple driver for the assembler, and the
subdirectory internal/asm, which contains the parser and
instruction generator.
It's likely that much of the implementation is superstition,
or at best experimental phenomenology, but it does generate
working binaries.
Change-Id: I322a9ae8a20174b6693153f30e39217ba68f8032
Reviewed-on: https://go-review.googlesource.com/3196
Reviewed-by: Russ Cox <rsc@golang.org>
Add the lexing code for the new portable assembler.
It is internal to the assembler, so lives in a subdirectory of cmd/asm/internal.
Its only new dependency is the flags package for the assembler, so
add that too; it's trivial. That package manages the command-line
flags in a central place.
The lexer builds on text/scanner to lex the input, including doing a
Plan 9-level implementation of the C preprocessor.
Change-Id: I262e8717b8c797010afaa5051920839906c0dd19
Reviewed-on: https://go-review.googlesource.com/3195
Reviewed-by: Russ Cox <rsc@golang.org>
This simple package holds the definition of the Addr (address) type
that represents addresses inside the assembler.
It has no dependencies.
Change-Id: I7573fd70f1847ef68e3d6b663dc4c39eb2ebf8b3
Reviewed-on: https://go-review.googlesource.com/3193
Reviewed-by: Russ Cox <rsc@golang.org>
This package builds the representation of the machine architecture
for the new assembler.
Almost nothing in it is likely to last but this will get things running.
Change-Id: I8edd891f927a81f76d2dbdcd7484b9c87ac0fb2e
Reviewed-on: https://go-review.googlesource.com/3194
Reviewed-by: Russ Cox <rsc@golang.org>
Rename itod to uitoa to have consistent naming with other itoa functions.
Reduce redundant code by calling uitoa from itoa.
Reduce buffer to maximally needed size for conversion of 64bit integers.
Adjust calls to itoa functions in package net to use new name for itod.
Avoid calls to itoa if uitoa suffices.
Change-Id: I79deaede4d4b0c076a99a4f4dd6f644ba1daec53
Reviewed-on: https://go-review.googlesource.com/2212
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
The compiler has a phase ordering problem. Escape analysis runs
before wrapper generation. When a generated wrapper calls a method
defined in a different package, if that call is inlined, there will be
no escape information for the variables defined in the inlined call.
Those variables will be placed on the stack, which fails if they
actually do escape.
There are probably various complex ways to fix this. This is a simple
way to avoid it: when a generated wrapper calls a method defined in a
different package, treat all local variables as escaping.
Fixes#9537.
Change-Id: I530f39346de16ad173371c6c3f69cc189351a4e9
Reviewed-on: https://go-review.googlesource.com/3092
Reviewed-by: Russ Cox <rsc@golang.org>
cmd/internal/obj reconverted using rsc.io/c2go rev 40275b8.
All Prog*s need Ctxt field set so that the printer can tell
which architecture the Prog belongs to.
Use ctxt.NewProg consistently for this.
Change-Id: Ic981b3d68f24931ffae74a772e83a3dc2fdf518a
Reviewed-on: https://go-review.googlesource.com/3152
Reviewed-by: Rob Pike <r@golang.org>
The build was broken on Plan 9 after the
CL 2994, because of the use of getfields
in src/liblink/go.c.
This happened when building 8l, because
getfield was part of lib9 and tokenize
was part of the Plan 9 libc. However,
both getfields and tokenize depend on
utfrune, causing an incompatibility.
This change enables the build of tokenize
as part of lib9, so it doesn't use
tokenize from the Plan 9 libc anymore.
Change-Id: I2a76903b508bd92771c4754cd53dfc64df350892
Reviewed-on: https://go-review.googlesource.com/3121
Reviewed-by: Minux Ma <minux@golang.org>
Adjust triggergc so that we trigger when we have used 7/8
of the available heap memory. Do first collection when we
exceed 4Mbytes.
Change-Id: I467b4335e16dc9cd1521d687fc1f99a51cc7e54b
Reviewed-on: https://go-review.googlesource.com/3149
Reviewed-by: Austin Clements <austin@google.com>
For new assembler, reconvert using rsc.io/c2go rev f9db76e.
- Removes trailing _ from Go keywords that are exported.
- Export regstr as Register, anames[5689] as Anames.
Also update clients.
Change-Id: I41c8fd2d14490236f548b4aa0ed0b9bd7571d2d7
Reviewed-on: https://go-review.googlesource.com/3151
Reviewed-by: Rob Pike <r@golang.org>
The function getgohostos and getgohostarch
were declared in include/libc.h in CL 3042.
Change-Id: Ib4ff5182cb71cc79a99663ce727fa4c28d15d7ad
Reviewed-on: https://go-review.googlesource.com/3122
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The function runcmd was declared in
include/libc.h in CL 7523043.
Change-Id: I3839b96b2ac0d63e5c2eb4c216710442d0962119
Reviewed-on: https://go-review.googlesource.com/3125
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Signer is an interface to support opaque private keys.
These keys typically result from being kept in special hardware
(i.e. a TPM) although sometimes operating systems provide a
similar interface using process isolation for security rather
than hardware boundaries.
This changes provides updates implements crypto.Signer in
CreateCRL and CreateCertificate so that they can be used with
opaque keys.
This CL has been discussed at: http://golang.org/cl/145910043
Change-Id: Id7857fb9a3b4c957c7050b519552ef1c8e55461e
Reviewed-on: https://go-review.googlesource.com/3126
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
When an assembly file must be assembled, cmd/go now runs
both (say) 6a and new6a and checks that they write identical
output files.
This serves as a build-time test that the new assemblers are accurate
conversions of the old ones. As long as they are producing identical
bytes, there's no need for run-time testing.
Once the C conversion is done, we'll throw away the C code
and this checking.
Change-Id: I0216dad56b7e79011eecd27f1aff4fe79bfe720b
Reviewed-on: https://go-review.googlesource.com/3145
Reviewed-by: Rob Pike <r@golang.org>
The change to the bootstrap import conversion is
for the a.y files, which use import dot.
While we're editing the tool list, add "cmd/dist".
Right now 'go install cmd/dist' installs to $GOROOT/bin/dist.
(A new bug since cmd/dist has been rewritten in Go.
When cmd/dist was a C program, go install cmd/dist just didn't work.)
Change-Id: I362208dcfb4ae64c987f60b95dc946829fa506d8
Reviewed-on: https://go-review.googlesource.com/3144
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
These assemblers produce byte-for-byte identical output
to the ones written in C.
They are primarily a proof that cmd/internal/obj can be used
standalone to produce working object files. (The use via objwriter
starts by deserializing an already-constructed internal representation,
so objwriter does not exercise the code in cmd/internal/obj that
creates such a representation from scratch.)
Change-Id: I1793d8d010046cfb9d8b4d2d4469e7f47a3d3ac7
Reviewed-on: https://go-review.googlesource.com/3143
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is the raw output of c2go. It needs fixes to make it compile.
Rather than make c2go do a 100% conversion (like we're doing for
liblink and the Go compilers), since this is so trivial I'm going to
make the remaining changes by hand in a followup CL.
This CL makes the next CL's diffs useful.
Also copy unmodified .y files (5a/a.y → new5a/a.y and so on)
The converted 6a/lex.c has been written to new6a/lex.go
but also to internal/asm/asm.go, because I'm going to factor
out some common code rather than convert it four times.
Change-Id: I01d5dfd6a9be3ef6191581560bdddd0ac0e8bc58
Reviewed-on: https://go-review.googlesource.com/3142
Reviewed-by: Rob Pike <r@golang.org>
Using rsc.io/c2go repo revision 60c9302.
- Export a few symbols needed by assemblers.
- Implement Getgoroot etc directly, and add Getgoversion.
- Removes dependency on Go 1.4 go/build.
- Change magic history name <no name> to <pop>
The <pop> change requires adjustment to the liblink serializer.
Change-Id: If5fb52ac9e91d50805263070b3fc5cc05d8b7632
Reviewed-on: https://go-review.googlesource.com/3141
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
cmd/internal/obj needs information about the default
values of GOROOT, GOARM, GOEXPERIMENT, Version, and so on.
It cannot ask package runtime, because during bootstrap
package runtime comes from Go 1.4.
So it must have its own copy.
Change-Id: I73d3e75a3d47210b3184a51a810ebb44826b81e5
Reviewed-on: https://go-review.googlesource.com/3140
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Adujst triggergc so that we trigger when we have used 7/8
of the available memory.
Change-Id: I7ca02546d3084e6a04d60b09479e04a9a9837ae2
Reviewed-on: https://go-review.googlesource.com/3061
Reviewed-by: Russ Cox <rsc@golang.org>
This CL enables moving the bulk of the object writing code
out of liblink and into translated Go libraries in cmd/internal/obj,
but it does not do the move.
This CL introduces two new environment variables,
$GOOBJ and $GOOBJWRITER, but both will be deleted along with
the rest of the liblink C code.
The default behavior of a build is unchanged by this CL:
the C version of liblink uses the C object layout and writing code.
If $GOOBJ=1, liblink invokes go tool objwriter instead.
If $GOOBJ=2, liblink does its own layout and then invokes
go tool objwriter, which checks that it gets the same answer.
That is, in $GOOBJ=2 mode, both the C and the Go version of
the code run, and the operation fails if the two produce different
answers. This provides a very strong check that the translation
is working correctly.
Change-Id: I56ab49b07ccb2c7b81085f1d6950131047c6aa3c
Reviewed-on: https://go-review.googlesource.com/3048
Reviewed-by: Ian Lance Taylor <iant@golang.org>
New code but nothing interesting.
It's nearly all parsing code for the format written by liblink.
The interesting part is the call to obj.Writeobjdirect, which
is the Go translation of the C liblink writeobjdirect function.
Change-Id: I2e9e755e7a3c999302e2ef2c7475c0af9c5acdd2
Reviewed-on: https://go-review.googlesource.com/3047
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL adds the real cmd/internal/obj packages.
Collectively they correspond to the liblink library.
The conversion was done using rsc.io/c2go's run script
at rsc.io/c2go repo version 706fac7.
This is not the final conversion, just the first working draft.
There will be more updates, but this works well enough
to use with go tool objwriter and pass all.bash.
Change-Id: I9359e835425f995a392bb2fcdbebf29511477bed
Reviewed-on: https://go-review.googlesource.com/3046
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Executing 'clean -i std' removes installed Go programs,
including the toolchain binaries we need for building.
It's not clear why the 'clean -i std' is here in the first place.
cmd/dist just removed the entire pkg tree, so everything is new.
The only reason for 'clean -i std' would be if you don't trust
that dist compiled the packages properly. If that's true for
some reason, we can fix cmd/dist, or add -a to the install
commands that follow. Perhaps clean -i std should not
remove tools, or perhaps std should not expand to any tools.
Not sure.
Also remove banner from make.bat and make.rc that was
already removed from make.bash. cmd/dist prints it now.
Also fix array size error in liblink/objfile.c.
Fixes dev.cc build.
Change-Id: I60855e001a682efce55ad9aa307a8f3ee47f7366
Reviewed-on: https://go-review.googlesource.com/3100
Reviewed-by: Russ Cox <rsc@golang.org>
This doesn't actually use objwriter for any real work.
It's just to check that objwriter is available.
The real work will be moved once the bootstrapping
mechanisms are working.
Change-Id: I5f41c8910c4b11b9d80cb0b0847ff9cb582fc2be
Reviewed-on: https://go-review.googlesource.com/3045
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Bootstrap the Go parts of the Go toolchain using Go 1.4,
as described in https://golang.org/s/go15bootstrap.
The first Go part of the Go toolchain will be cmd/objwriter,
but for now that's just an empty program to test that this
new code works.
Once the build dashboard is okay with this change,
we'll make objwriter a real program depended upon by the build.
Change-Id: Iad3dce675571cbdb5ab6298fe6f98f53ede47d5c
Reviewed-on: https://go-review.googlesource.com/3044
Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/internal/obj is the name for the Go translation of the C liblink library.
cmd/objwriter is the name of a Go binary that runs liblink's writeobj function.
When the bulk of liblink has been converted to Go but the assemblers and
compilers are still written in C, the C writeobj will shell out to the Go objwriter
to actually write the object file. This lets us manage the transition in smaller
pieces.
The objwriter tool is purely transitional.
It will not ship in any release (enforced in cmd/dist).
Adding a dummy program and some dummy imports here so that we
can work on the bootstrap mechanisms that will be necessary to build it.
Once the build process handles objwriter properly,
we'll work on the actual implementation.
Change-Id: I675c818b3a513c26bb91c6dba564c6ace3b7fcd4
Reviewed-on: https://go-review.googlesource.com/3043
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Needed for invoking a Go subprocess in the C code.
The Go tools live in $GOROOT/pkg/tool/$GOHOSTARCH_$GOHOSTOS.
Change-Id: I961b6b8a07de912de174b758b2fb87d77080546d
Reviewed-on: https://go-review.googlesource.com/3042
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The argument is unused in the C code but will be used in the Go translation,
because the Prog holds information needed to invoke the right meaning
of %A in the ctxt->diag calls in vaddr.
Change-Id: I501830f8ea0e909aafd8ec9ef5d7338e109d9548
Reviewed-on: https://go-review.googlesource.com/3041
Reviewed-by: Ian Lance Taylor <iant@golang.org>
According to RFC5280 the authority key identifier extension MUST included in all
CRLs issued. This patch includes the authority key identifier extension when the
Subject Key Identifier is present in the signing certificate.
RFC5280 states:
"The authority key identifier extension provides a means of identifying the
public key corresponding to the private key used to sign a CRL. The
identification can be based on either the key identifier (the subject key
identifier in the CRL signer's certificate) or the issuer name and serial
number. This extension is especially useful where an issuer has more than one
signing key, either due to multiple concurrent key pairs or due to changeover."
Conforming CRL issuers MUST use the key identifier method, and MUST include this
extension in all CRLs issued."
This CL has been discussed at: http://golang.org/cl/177760043
Change-Id: I9bf50521908bfe777ea2398f154c13e8c90d14ad
Reviewed-on: https://go-review.googlesource.com/2258
Reviewed-by: Adam Langley <agl@golang.org>
Signer is an interface to support opaque private keys.
These keys typically result from being kept in special hardware
(i.e. a TPM) although sometimes operating systems provide a
similar interface using process isolation for security rather
than hardware boundaries.
This changes provides updates implements crypto.Signer in
CreateCRL and CreateCertificate so that they can be used with
opaque keys.
This CL has been discussed at: http://golang.org/cl/145910043
Change-Id: Ie4a4a583fb120ff484a5ccf267ecd2a9c5a3902b
Reviewed-on: https://go-review.googlesource.com/2254
Reviewed-by: Adam Langley <agl@golang.org>
Unless the first element is a Universal Naming Convention (UNC)[0]
path, Join shouldn't create a UNC path on Windows.
For example, Join inadvertently creates a UNC path on Windows when
told to join at least three non-empty path elements, where the first
element is `\` or `/`.
This CL prevents creation of a UNC path prefix when the first path
element isn't a UNC path.
Since this introduces some amount of Windows-specific logic, Join is
moved to a per GOOS implementation.
Fixes#9167.
[0]: http://msdn.microsoft.com/en-us/library/gg465305.aspx
Change-Id: Ib6eda597106cb025137673b33c4828df1367f75b
Reviewed-on: https://go-review.googlesource.com/2211
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Print out the object holding the reference to the object
that checkmark detects as not being properly marked.
Change-Id: Ieedbb6fddfaa65714504af9e7230bd9424cd0ae0
Reviewed-on: https://go-review.googlesource.com/2744
Reviewed-by: Austin Clements <austin@google.com>
Close the pipe for the body of a request when it is aborted and close
all pipes when child.serve terminates.
Fixes#6934
Change-Id: I1c5e7d2116e1ff106f11a1ef8e99bf70cf04162a
Reviewed-on: https://go-review.googlesource.com/1923
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Can't use bgwait, both because it can only be used from
one goroutine at a time and because it ends up queued
behind all the other pending commands. Use a separate
signaling mechanism so that we can notice we're dying
sooner.
Change-Id: I8652bfa2f9bb5725fa5968d2dd6a745869d01c01
Reviewed-on: https://go-review.googlesource.com/3010
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The code in mfinal.go is moved from malloc*.go and mgc*.go
and substantially unchanged.
The code in mbitmap.go is also moved from those files, but
cleaned up so that it can be called from those files (in most cases
the code being moved was not already a standalone function).
I also renamed the constants and wrote comments describing
the format. The result is a significant cleanup and isolation of
the bitmap code, but, roughly speaking, it should be treated
and reviewed as new code.
The other files changed only as much as necessary to support
this code movement.
This CL does NOT change the semantics of the heap or type
bitmaps at all, although there are now some obvious opportunities
to do so in followup CLs.
Change-Id: I41b8d5de87ad1d3cd322709931ab25e659dbb21d
Reviewed-on: https://go-review.googlesource.com/2991
Reviewed-by: Keith Randall <khr@golang.org>
I also added new comments at the top of mbarrier.go,
but the rest of the code is just copy-and-paste.
Change-Id: Iaeb2b12f8b1eaa33dbff5c2de676ca902bfddf2e
Reviewed-on: https://go-review.googlesource.com/2990
Reviewed-by: Austin Clements <austin@google.com>
Otherwise, if you mistakenly refer to an undeclared 'shift' variable, you get 52.
Change-Id: I845fb29f23baee1d8e17b37bde0239872eb54316
Reviewed-on: https://go-review.googlesource.com/2909
Reviewed-by: Austin Clements <austin@google.com>
As shown in #9395, inaccurate implementation would be a cause of parsing
IPv4 header twice and corrupted upper-layer message issues.
Change-Id: Ia1a042e7ca58ee4fcb38fe9ec753c2ab100592ca
Reviewed-on: https://go-review.googlesource.com/3001
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The function is here ONLY for symmetry with package bytes.
This function should be used ONLY if it makes code clearer.
It is not here for performance. Remove any performance benefit.
If performance becomes an issue, the compiler should be fixed to
recognize the three-way compare (for all comparable types)
rather than encourage people to micro-optimize by using this function.
Change-Id: I71f4130bce853f7aef724c6044d15def7987b457
Reviewed-on: https://go-review.googlesource.com/3012
Reviewed-by: Rob Pike <r@golang.org>
cmd/dist now requires $GOROOT to be set explicitly.
Set it when invoking via 'go tool dist' so that users are unaffected.
Also, change go tool -n to drop trailing space in output
for 'go tool -n <anything>'.
Change-Id: I9b2c020e0a2f3fa7c9c339fadcc22cc5b6cb7cac
Reviewed-on: https://go-review.googlesource.com/3011
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Since the move to Github, we've started to receive lots of
introductory questions to the bug tracker. I posit this is because
most projects on Github don't have mailing lists, so the culture on
Github is to use the Issue Tracker as a discussion forum.
The Go project doesn't use the Issue Tracker as our first point of
communication. This CL updates CONTRIBUTING.md (which is linked when
you file a bug or send a pull request), to mention that we have a
mailing list.
It certainly won't stop all the errant bug reports, but it should
help.
Change-Id: Id8fbfd35b73f5117617dff53b1e72d5b5276388b
Reviewed-on: https://go-review.googlesource.com/3002
Reviewed-by: Rob Pike <r@golang.org>
Cygwin perl uses unix pathnames in windows. Include cygwin perl in the
list of special cases for unix pathname handling in test.cgi.
Change-Id: I30445a9cc79d62d022ecc232c35aa5015b7418dc
Reviewed-on: https://go-review.googlesource.com/2973
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This brings in cmd/dist written in Go, which is working on the primary builders.
If this breaks your build, you need to get Go 1.4 and put it in $HOME/go1.4
(or, if you want to use some other directory, set $GOROOT_BOOTSTRAP
to that directory).
To build Go 1.4 from source:
git clone -b release-branch.go1.4 $GOROOT $HOME/go1.4
cd $HOME/go1.4/src
./make.bash
Or use a binary release: https://golang.org/dl/.
See https://golang.org/s/go15bootstrap for more information.
Change-Id: Ie4ae834c76ea35e39cc54e9878819a9e51b284d9
This change includes the cleanup of temporary files created during
the binary execution as well.
Change-Id: Ic01a0a537d1daafcaa3acda1ec344aff5dcddfc2
Reviewed-on: https://go-review.googlesource.com/2903
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This test requires external linking, but we don't yet implement
external linking on ppc64 (tracked in issue #8912). Disable the test
on ppc64 until external linking is implemented.
This makes all.bash pass on ppc64le.
Change-Id: I741498d4d9321607e7a65792a33faf8187bd18e4
Reviewed-on: https://go-review.googlesource.com/2908
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The comment says to use (y-1), but then we did add(y.abs, natOne). We meant sub.
Fixes#9609
Change-Id: I4fe4783326ca082c05588310a0af7895a48fc779
Reviewed-on: https://go-review.googlesource.com/2961
Reviewed-by: Robert Griesemer <gri@golang.org>
Generated with a modified version of go vet and tested on android.
Change-Id: I1ff20135c5ab9de5a6dbf76ea2991167271ee70d
Reviewed-on: https://go-review.googlesource.com/2815
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We were failing ^uint16(0xffff) == 0, as we computed 0xffff0000 instead.
I could only trigger a failure for the above case, the other two tests
^uint16(0xfffe) == 1 and -uint16(0xffff) == 1 didn't seem to fail
previously. Somehow they get MOVHUs inserted for other reasons (used
by CMP instead of TST?). I fixed OMINUS anyway, better safe than
sorry.
Fixes#9604
Change-Id: I4c2d5bdc667742873ac029fdbe3db0cf12893c27
Reviewed-on: https://go-review.googlesource.com/2940
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Git marks some of its files read only, so os.RemoveAll isn't sufficient
to remove them from the ".git" directory.
Change-Id: I3150596931d1c77e7cf9fb8da1a999d2c6730121
Reviewed-on: https://go-review.googlesource.com/2930
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
androidtest.bash copies some go source to the android device
where the tests are going to run. It's necessary because some
tests require files and resources to be present. The copy is
done through adb sync. The script hoped faking the directory
using symlinks to work, but it doesn't. (adb sync doesn't follow
the symlinks) We need proper copy.
Change-Id: If55abca4958f159859e58512b0045f23654167e3
Reviewed-on: https://go-review.googlesource.com/2827
Reviewed-by: David Crawshaw <crawshaw@golang.org>
runtime.rtype was a copy of reflect.rtype - update script to use that directly.
Introduces a basic test which will skip on systems without appropriate GDB.
Fixes#9326
Change-Id: I6ec74e947bd2e1295492ca34b3a8c1b49315a8cb
Reviewed-on: https://go-review.googlesource.com/2821
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Do not lose precision for durations specified without fractions
that can be represented by an int64 such as 1<<53+1 nanoseconds.
Previously there was some precision lost in floating point conversion.
Handle overflow for durations above 1<<63-1 nanoseconds but not earlier.
Add tests to cover the above cases.
Change-Id: I4bcda93cee1673e501ecb6a9eef3914ee29aecd2
Reviewed-on: https://go-review.googlesource.com/2461
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The various files are confusingly named and their operation
not easy to see. Add a comment to cmplxdivide.c, one of the few
C files that will endure in the repository, to explain how to build
and run the test.
Change-Id: I1fd5c564a14217e1b9815b09bc24cc43c54c096f
Reviewed-on: https://go-review.googlesource.com/2850
Reviewed-by: Russ Cox <rsc@golang.org>
6g does not implement dead code elimination for const switches like it
does for const if statements, so the undefined raiseproc() function
was resulting in a link-time failure.
Change-Id: Ie4fcb3716cb4fe6e618033071df9de545ab3e0af
Reviewed-on: https://go-review.googlesource.com/2830
Reviewed-by: Russ Cox <rsc@golang.org>
printf, vprintf, snprintf, gc_m_ptr, gc_g_ptr, gc_itab_ptr, gc_unixnanotime.
These were called from C.
There is no more C.
Now that vprintf is gone, delete roundup, which is unsafe (see CL 2814).
Change-Id: If8a7b727d497ffa13165c0d3a1ed62abc18f008c
Reviewed-on: https://go-review.googlesource.com/2824
Reviewed-by: Austin Clements <austin@google.com>
Moving the "don't really preempt" check up earlier in the function
introduced a race where gp.stackguard0 might change between
the early check and the later one. Since the later one is missing the
"don't really preempt" logic, it could decide to preempt incorrectly.
Pull the result of the check into a local variable and use an atomic
to access stackguard0, to eliminate the race.
I believe this will fix the broken OS X and Solaris builders.
Change-Id: I238350dd76560282b0c15a3306549cbcf390dbff
Reviewed-on: https://go-review.googlesource.com/2823
Reviewed-by: Austin Clements <austin@google.com>
Since CL 2750, the build is broken on Plan 9,
because a new function netpollinited was added
and called from findrunnable in proc1.go.
However, netpoll is not implemented on Plan 9.
Thus, we define netpollinited in netpoll_stub.go.
Fixes#9590
Change-Id: I0895607b86cbc7e94c1bfb2def2b1a368a8efbe6
Reviewed-on: https://go-review.googlesource.com/2759
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
These were fixed in my local commit,
but I forgot that the web Submit button can't see that.
Change-Id: Iec3a70ce3ccd9db2a5394ae2da0b293e45ac2fb5
Reviewed-on: https://go-review.googlesource.com/2822
Reviewed-by: Russ Cox <rsc@golang.org>
During all.bash I got a crash in the GOMAXPROCS=2 runtime test reporting
that the write barrier in the assignment 'c.tiny = add(x, size)' had been
given a pointer pointing into an unexpected span. The problem is that
the tiny allocation was at the end of a span and c.tiny was now pointing
to the end of the allocation and therefore to the end of the span aka
the beginning of the next span.
Rewrite tinyalloc not to do that.
More generally, it's not okay to call add(p, size) unless you know that p
points at > (not just >=) size bytes. Similarly, pretty much any call to
roundup doesn't know how much space p points at, so those are all
broken.
Rewrite persistentalloc not to use add(p, totalsize) and not to use roundup.
There is only one use of roundup left, in vprintf, which is dead code.
I will remove that code and roundup itself in a followup CL.
Change-Id: I211e307d1a656d29087b8fd40b2b71010722fb4a
Reviewed-on: https://go-review.googlesource.com/2814
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
It could happen that mp.printlock++ happens, then on entry to lock,
the goroutine is preempted and then rescheduled onto another m
for the actual call to lock. Now the lock and the printlock++ have
happened on different m's. This can lead to printlock not being
unlocked, which either gives a printing deadlock or a crash when
the goroutine reschedules, because m.locks > 0.
Change-Id: Ib0c08740e1b53de3a93f7ebf9b05f3dceff48b9f
Reviewed-on: https://go-review.googlesource.com/2819
Reviewed-by: Rick Hudson <rlh@golang.org>
Go 1.4 should build what it knows how to build.
GOHOSTOS and GOHOSTARCH are for the Go 1.5 build only.
Change-Id: Id0f367f03485100a896e61cfdace4ac44a22e16d
Reviewed-on: https://go-review.googlesource.com/2818
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Mostly this is using uint32 instead of int32 for unsigned values
like instruction encodings or float32 bit representations,
removal of ternary operations, and removal of #defines.
Delete sched9.c, because it is not compiled (it is still in the history
if we ever need it).
Change-Id: I68579cfea679438a27a80416727a9af932b088ae
Reviewed-on: https://go-review.googlesource.com/2658
Reviewed-by: Austin Clements <austin@google.com>
Normally, a panic/throw only shows the thread stack for the current thread
and all paused goroutines. Goroutines running on other threads, or other threads
running on their system stacks, are opaque. Change that when GODEBUG=crash,
by passing a SIGQUIT around to all the threads when GODEBUG=crash.
If this works out reasonably well, we might make the SIGQUIT relay part of
the standard panic/throw death, perhaps eliding idle m's.
Change-Id: If7dd354f7f3a6e326d17c254afcf4f7681af2f8b
Reviewed-on: https://go-review.googlesource.com/2811
Reviewed-by: Rick Hudson <rlh@golang.org>
There is a small possibility that runtime deadlocks when netpoll is just activated.
Consider the following scenario:
GOMAXPROCS=1
epfd=-1 (netpoll is not activated yet)
A thread is in findrunnable, sets sched.lastpoll=0, calls netpoll(true),
which returns nil. Now the thread is descheduled for some time.
Then sysmon retakes a P from syscall and calls handoffp.
The "If this is the last running P and nobody is polling network" check in handoffp fails,
since the first thread set sched.lastpoll=0. So handoffp decides that there is already
a thread that polls network and so it calls pidleput.
Now the first thread is scheduled again, finds no work and calls stopm.
There is no thread that polls network and so checkdead reports deadlock.
To fix this, don't set sched.lastpoll=0 when netpoll is not activated.
The deadlock can happen if cgo is disabled (-tag=netgo) and only on program startup
(when netpoll is just activated).
The test is from issue 5216 that lead to addition of the
"If this is the last running P and nobody is polling network" check in handoffp.
Update issue 9576.
Change-Id: I9405f627a4d37bd6b99d5670d4328744aeebfc7a
Reviewed-on: https://go-review.googlesource.com/2750
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The old name was too ambiguous (is it a verb? is it a predicate? is
it a constant?) and too close to debug.gccheckmark. Hopefully the new
name conveys that this variable indicates that we are currently doing
mark checking.
Change-Id: I031cd48b0906cdc7774f5395281d3aeeb8ef3ec9
Reviewed-on: https://go-review.googlesource.com/2656
Reviewed-by: Rick Hudson <rlh@golang.org>
1) Move non-preemption check even earlier in newstack.
This avoids a few priority inversion problems.
2) Always use atomic operations to update bitmap for 1-word objects.
This avoids lost mark bits during concurrent GC.
3) Stop using work.nproc == 1 as a signal for being single-threaded.
The concurrent GC runs with work.nproc == 1 but other procs are
running mutator code.
The use of work.nproc == 1 in getfull *is* safe, but remove it anyway,
since it is saving only a single atomic operation per GC round.
Fixes#9225.
Change-Id: I24134f100ad592ea8cb59efb6a54f5a1311093dc
Reviewed-on: https://go-review.googlesource.com/2745
Reviewed-by: Rick Hudson <rlh@golang.org>
https://go-review.googlesource.com/#/c/1876/ introduced a new
TestClipWithNilMP test, along with a code change that fixed a panic,
but the existing TestClip test already contained almost enough machinery
to cover that bug.
There is a small code change in this CL, but it is a no-op: (*x).y is
equivalent to x.y for a pointer-typed x, but the latter is cleaner.
Change-Id: I79cf6952a4999bc4b91f0a8ec500acb108106e56
Reviewed-on: https://go-review.googlesource.com/2304
Reviewed-by: Dave Cheney <dave@cheney.net>
Make auxv parsing in linux/arm less of a special case.
* rename setup_auxv to sysargs
* exclude linux/arm from vdso_none.go
* move runtime.checkarm after runtime.sysargs so arm specific
values are properly initialised
Change-Id: I1ca7f5844ad5a162337ff061a83933fc9a2b5ff6
Reviewed-on: https://go-review.googlesource.com/2681
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fix SmartOS build that was broken in 682922908f.
SmartOS pretends to be Ubuntu/Debian with respect to its SSL
certificate location.
Change-Id: I5405c6472c8a1e812e472e7301bf6084c17549d6
Reviewed-on: https://go-review.googlesource.com/2704
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For some cases we can ensure the correct order of elements in two
instead of three comparisons. It is unnecessary to compare m0 and
m1 again if m2 and m1 are not swapped.
benchmark old ns/op new ns/op delta
BenchmarkSortString1K 302721 299590 -1.03%
BenchmarkSortInt1K 124055 123215 -0.68%
BenchmarkSortInt64K 12291522 12203402 -0.72%
BenchmarkSort1e2 58027 57111 -1.58%
BenchmarkSort1e4 12426805 12341761 -0.68%
BenchmarkSort1e6 1966250030 1960557883 -0.29%
Change-Id: I2b17ff8dee310ec9ab92a6f569a95932538768a9
Reviewed-on: https://go-review.googlesource.com/2614
Reviewed-by: Robert Griesemer <gri@golang.org>
This change implements the requirement of
old Go to build new Go on Plan 9. Also fix
the build of the new cmd/dist written in Go.
This is similar to the make.bash change in
CL 2470, but applied to make.rc for Plan 9.
Change-Id: Ifd9a3bd8658e2cee6f92b4c7f29ce86ee2a93c53
Reviewed-on: https://go-review.googlesource.com/2662
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In the previous sandbox implementation we read all sandboxed output
from standard output, and so all fake time writes were made to
standard output. Now we have a more sophisticated sandbox server
(see golang.org/x/playground/sandbox) that is capable of recording
both standard output and standard error, so allow fake time writes to
go to either file descriptor.
Change-Id: I79737deb06fd8e0f28910f21f41bd3dc1726781e
Reviewed-on: https://go-review.googlesource.com/2713
Reviewed-by: Minux Ma <minux@golang.org>
Skip the allocation testing (which was only used as a signal for
whether the interface was implemented by ResponseWriter), and just
test for it directly.
Fixes#9575
Change-Id: Ie230f1d21b104537d5647e9c900a81509d692469
Reviewed-on: https://go-review.googlesource.com/2720
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
RFC5280 states:
"This optional field describes the version of the encoded CRL. When
extensions are used, as required by this profile, this field MUST be
present and MUST specify version 2 (the integer value is 1)."
This CL has been discussed at: http://golang.org/cl/172560043
Change-Id: I8a72d7593d5ca6714abe9abd6a37437c3b69ab0f
Reviewed-on: https://go-review.googlesource.com/2259
Reviewed-by: Adam Langley <agl@golang.org>
And add names for the curve implemented in crypto/elliptic.
This permits a safer alternative to switching on BitSize
for code that implements curve-dependent cryptosystems.
(E.g., ECDSA on P-xxx curves with the matched SHA-2
instances.)
Change-Id: I653c8f47506648028a99a96ebdff8389b2a95fc1
Reviewed-on: https://go-review.googlesource.com/2133
Reviewed-by: Adam Langley <agl@golang.org>
According to RFC4055 a NULL parameter MUST be present in the signature
algorithm. This patch adds the NULL value to the Signature Algorithm
parameters in the signingParamsForPrivateKey function for RSA based keys.
Section 2.1 states:
"There are two possible encodings for the AlgorithmIdentifier
parameters field associated with these object identifiers. The two
alternatives arise from the loss of the OPTIONAL associated with the
algorithm identifier parameters when the 1988 syntax for
AlgorithmIdentifier was translated into the 1997 syntax. Later the
OPTIONAL was recovered via a defect report, but by then many people
thought that algorithm parameters were mandatory. Because of this
history some implementations encode parameters as a NULL element
while others omit them entirely. The correct encoding is to omit the
parameters field; however, when RSASSA-PSS and RSAES-OAEP were
defined, it was done using the NULL parameters rather than absent
parameters.
All implementations MUST accept both NULL and absent parameters as
legal and equivalent encodings.
To be clear, the following algorithm identifiers are used when a NULL
parameter MUST be present:
sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL }
sha224Identifier AlgorithmIdentifier ::= { id-sha224, NULL }
sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL }
sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL }
sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL }"
This CL has been discussed at: http://golang.org/cl/177610043
Change-Id: Ic782161938b287f34f64ef5eb1826f0d936f2f71
Reviewed-on: https://go-review.googlesource.com/2256
Reviewed-by: Adam Langley <agl@golang.org>
While we're here, rename TestIssue7234 to Test7234 for consistency
with other tests.
Fixes#9557.
Change-Id: I22b0a212b31e7b4f199f6a70deb73374beb80f84
Reviewed-on: https://go-review.googlesource.com/2654
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Please see golang.org/cl/2588 for reasons behind the name change.
We also need NO_LOCAL_POINTERS for assembly function with non-zero
local frame size.
Change-Id: Iac60aa7e76f4c2ece3726e28878fd539bfebf7a4
Reviewed-on: https://go-review.googlesource.com/2589
Reviewed-by: Ian Lance Taylor <iant@golang.org>
* Use WORD declaration so 5a can't rewrite the instruction or complain
about forms it doesn't know about.
* Add the interpunct to function declaration.
Change-Id: I8494548db21b3ea52f0e1e0e547d9ead8b93dfd1
Reviewed-on: https://go-review.googlesource.com/2682
Reviewed-by: Minux Ma <minux@golang.org>
Previously, gccheckmark could only be enabled or disabled by calling
runtime.GCcheckmarkenable/GCcheckmarkdisable. This was a necessary
hack because GODEBUG was broken.
Now that GODEBUG works again, move control over gccheckmark to a
GODEBUG variable and remove these runtime functions. Currently,
gccheckmark is enabled by default (and will probably remain so for
much of the 1.5 development cycle).
Change-Id: I2bc6f30c21b795264edf7dbb6bd7354b050673ab
Reviewed-on: https://go-review.googlesource.com/2603
Reviewed-by: Rick Hudson <rlh@golang.org>
It was just an oversight that this one method of Logger was not
made available for the standard (std) Logger.
Fixes#9183
Change-Id: I2f251becdb0bae459212d09ea0e5e88774d16dea
Reviewed-on: https://go-review.googlesource.com/2686
Reviewed-by: Andrew Gerrand <adg@golang.org>
Renaming the function broke the race detector since it looked for the
name, didn't find it anymore and didn't insert the necessary
instrumentation.
Change-Id: I11fed6e807cc35be5724d26af12ceff33ebf4f7b
Reviewed-on: https://go-review.googlesource.com/2661
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
This CL introduces the bootstrap requirement that in order to
build the current release (or development version) of Go, you
need an older Go release (1.4 or newer) already installed.
This requirement is the whole point of this CL.
To enforce the requirement, convert cmd/dist from C to Go.
With this bootstrapping out of the way, we can move on to
replacing other, larger C programs like the Go compiler,
the assemblers, and the linker.
See golang.org/s/go15bootstrap for details.
Change-Id: I53fd08ddacf3df9fae94fe2c986dba427ee4a21d
Reviewed-on: https://go-review.googlesource.com/2470
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Also fix one unaligned stack size for nacl that is caught
by this change.
Fixes#9539.
Change-Id: Ib696a573d3f1f9bac7724f3a719aab65a11e04d3
Reviewed-on: https://go-review.googlesource.com/2600
Reviewed-by: Keith Randall <khr@golang.org>
CL 2520 omitted to set the type for an OCONVNOP node.
Typechecking obviously cannot do it for us.
5g inserts float64 <--> [u]int64 conversions at walk time.
The missing type caused it to crash.
Change-Id: Idce381f219bfef2e3a3be38d3ba3c258b71310ae
Reviewed-on: https://go-review.googlesource.com/2640
Reviewed-by: Keith Randall <khr@golang.org>
Recognize loops of the form
for i := range a {
a[i] = zero
}
in which the evaluation of a is free from side effects.
Replace these loops with calls to memclr.
This occurs in the stdlib in 18 places.
The motivating example is clearing a byte slice:
benchmark old ns/op new ns/op delta
BenchmarkGoMemclr5 3.31 3.26 -1.51%
BenchmarkGoMemclr16 13.7 3.28 -76.06%
BenchmarkGoMemclr64 50.8 4.14 -91.85%
BenchmarkGoMemclr256 157 6.02 -96.17%
Update #5373.
Change-Id: I99d3e6f5f268e8c6499b7e661df46403e5eb83e4
Reviewed-on: https://go-review.googlesource.com/2520
Reviewed-by: Keith Randall <khr@golang.org>
If an inbound connection is closed, cancel the outbound http request.
This is particularly useful if the outbound request may consume resources
unnecessarily until it is cancelled.
Fixes#8406
Change-Id: I738c4489186ce342f7e21d0ea3f529722c5b443a
Signed-off-by: Peter Waller <p@pwaller.net>
Reviewed-on: https://go-review.googlesource.com/2320
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reduce buffer to maximally needed size for conversion of 64bit integers.
Reduce number of used integer divisions.
benchmark old ns/op new ns/op delta
BenchmarkItoa 144 119 -17.36%
BenchmarkPrintln 783 752 -3.96%
Change-Id: I6d57a7feebf90f303be5952767107302eccf4631
Reviewed-on: https://go-review.googlesource.com/2215
Reviewed-by: Rob Pike <r@golang.org>
Random is bad, it can block and prevent binaries from starting.
Use urandom instead. We'd rather have bad random bits than no
random bits.
Change-Id: I360e1cb90ace5518a1b51708822a1dae27071ebd
Reviewed-on: https://go-review.googlesource.com/2582
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Minux Ma <minux@golang.org>
This is a replay of CL 189760043 that is in release-branch.go1.4,
but not in master branch somehow.
Change-Id: I11eb40a24273e7be397e092ef040e54efb8ffe86
Reviewed-on: https://go-review.googlesource.com/2541
Reviewed-by: Andrew Gerrand <adg@golang.org>
In 32-bit worlds, 8-byte objects are only aligned to 4-byte boundaries.
Change-Id: I91469a9a67b1ee31dd508a4e105c39c815ecde58
Reviewed-on: https://go-review.googlesource.com/2581
Reviewed-by: Keith Randall <khr@golang.org>
For a non-zero-sized struct with a final zero-sized field,
add a byte to the size (before rounding to alignment). This
change ensures that taking the address of the zero-sized field
will not incorrectly leak the following object in memory.
reflect.funcLayout also needs this treatment.
Fixes#9401
Change-Id: I1dc503dc5af4ca22c8f8c048fb7b4541cc957e0f
Reviewed-on: https://go-review.googlesource.com/2452
Reviewed-by: Russ Cox <rsc@golang.org>
Add compile time constants for bases 10 and 16 instead of computing the cutoff
value on every invocation of ParseUint by a division.
Reduce usage of slice operations.
amd64:
benchmark old ns/op new ns/op delta
BenchmarkAtoi 44.6 36.0 -19.28%
BenchmarkAtoiNeg 44.2 38.9 -11.99%
BenchmarkAtoi64 72.5 56.7 -21.79%
BenchmarkAtoi64Neg 66.1 58.6 -11.35%
386:
benchmark old ns/op new ns/op delta
BenchmarkAtoi 86.6 73.0 -15.70%
BenchmarkAtoiNeg 86.6 72.3 -16.51%
BenchmarkAtoi64 126 108 -14.29%
BenchmarkAtoi64Neg 126 108 -14.29%
Change-Id: I0a271132120d776c97bb4ed1099793c73e159893
Reviewed-on: https://go-review.googlesource.com/2460
Reviewed-by: Robert Griesemer <gri@golang.org>
run GC in its own background goroutine making the
caller runnable if resources are available. This is
critical in single goroutine applications.
Allow goroutines that allocate a lot to help out
the GC and in doing so throttle their own allocation.
Adjust test so that it only detects that a GC is run
during init calls and not whether the GC is memory
efficient. Memory efficiency work will happen later
in 1.5.
Change-Id: I4306f5e377bb47c69bda1aedba66164f12b20c2b
Reviewed-on: https://go-review.googlesource.com/2349
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This improves the printing of GC times to be both more human-friendly
and to provide enough information for the construction of MMU curves
and other statistics. The new times look like:
GC: #8 72413852ns @143036695895725 pause=622900 maxpause=427037 goroutines=11 gomaxprocs=4
GC: sweep term: 190584ns max=190584 total=275001 procs=4
GC: scan: 260397ns max=260397 total=902666 procs=1
GC: install wb: 5279ns max=5279 total=18642 procs=4
GC: mark: 71530555ns max=71530555 total=186694660 procs=1
GC: mark term: 427037ns max=427037 total=1691184 procs=4
This prints gomaxprocs and the number of procs used in each phase for
the benefit of analyzing mutator utilization during concurrent phases.
This also means the analysis doesn't have to hard-code which phases
are STW.
This prints the absolute start time only for the GC cycle. The other
start times can be derived from the phase durations. This declutters
the view for humans readers and doesn't pose any additional complexity
for machine readers.
This removes the confusing "cycle" terminology. Instead, this places
the phase duration after the phase name and adds a "ns" unit, which
both makes it implicitly clear that this is the duration of that phase
and indicates the units of the times.
This adds a "GC:" prefix to all lines for easier identification.
Finally, this generally cleans up the code as well as the placement of
spaces in the output and adds print locking so the statistics blocks
are never interrupted by other prints.
Change-Id: Ifd056db83ed1b888de7dfa9a8fc5732b01ccc631
Reviewed-on: https://go-review.googlesource.com/2542
Reviewed-by: Rick Hudson <rlh@golang.org>
Edge cases like base 2 and 36 conversions are now covered.
Many tests are mirrored from the itoa tests.
Added more test cases for syntax errors.
Change-Id: Iad8b2fb4854f898c2bfa18cdeb0cb4a758fcfc2e
Reviewed-on: https://go-review.googlesource.com/2463
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
I would like to create new syscalls in src/internal/syscall,
and I prefer not to add new shell scripts for that.
Replacement for CL 136000043.
Change-Id: I840116b5914a2324f516cdb8603c78973d28aeb4
Reviewed-on: https://go-review.googlesource.com/1940
Reviewed-by: Russ Cox <rsc@golang.org>
$GOTESTONLY controls which set of tests gets run. Only "std" is
supported. This should bring the time of plan9 builder down
from 90 minutes to a maybe 10-15 minutes when running on GCE.
(Plan 9 has performance problems when running on GCE, and/or with the
os/exec package)
This is a temporary workaround for one builder. The other Plan 9
builders will continue to do full builds. The plan9 buidler will be
renamed plan9-386-gcepartial or something to indicate it's not running
the 'test/*' directory, or API tests. Go on Plan 9 has bigger problems
for now. This lets us get trybots going sooner including Plan 9,
without waiting 90+ minutes.
Update #9491
Change-Id: Ic505e9169c6b304ed4029b7bdfb77bb5c8fa8daa
Reviewed-on: https://go-review.googlesource.com/2522
Reviewed-by: Rob Pike <r@golang.org>
SWIG has always returned a typed interface value for a C++ class,
so the interface value will never be nil even if the pointer itself
is NULL. ptr == NULL in C/C++ should be ptr.Swigcptr() == 0 in Go.
Fixes#9514.
Change-Id: I3778b91acf54d2ff22d7427fbf2b6ec9b9ce3b43
Reviewed-on: https://go-review.googlesource.com/2440
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Now that there's no 6c compiler anymore, there's no need for cgo to
generate C headers that are compatible with it.
Fixes#9528
Change-Id: I43f53869719eb9a6065f1b39f66f060e604cbee0
Reviewed-on: https://go-review.googlesource.com/2482
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The compiler converts 'val, ok = m[key]' to
tmp, ok = <runtime call>
val = *tmp
For lookups of the form '_, ok = m[key]',
the second statement is unnecessary.
By not generating it we save a nil check.
Change-Id: I21346cc195cb3c62e041af8b18770c0940358695
Reviewed-on: https://go-review.googlesource.com/1975
Reviewed-by: Russ Cox <rsc@golang.org>
The equal algorithm used to take the size
equal(p, q *T, size uintptr) bool
With this change, it does not
equal(p, q *T) bool
Similarly for the hash algorithm.
The size is rarely used, as most equal functions know the size
of the thing they are comparing. For instance f32equal already
knows its inputs are 4 bytes in size.
For cases where the size is not known, we allocate a closure
(one for each size needed) that points to an assembly stub that
reads the size out of the closure and calls generic code that
has a size argument.
Reduces the size of the go binary by 0.07%. Performance impact
is not measurable.
Change-Id: I6e00adf3dde7ad2974adbcff0ee91e86d2194fec
Reviewed-on: https://go-review.googlesource.com/2392
Reviewed-by: Russ Cox <rsc@golang.org>
Use a lookup table to find the function which contains a pc. It is
faster than the old binary search. findfunc is used primarily for
stack copying and garbage collection.
benchmark old ns/op new ns/op delta
BenchmarkStackCopy 294746596 255400980 -13.35%
(findfunc is one of several tasks done by stack copy, the findfunc
time itself is about 2.5x faster.)
The lookup table is built at link time. The table grows the binary
size by about 0.5% of the text segment.
We impose a lower limit of 16 bytes on any function, which should not
have much of an impact. (The real constraint required is <=256
functions in every 4096 bytes, but 16 bytes/function is easier to
implement.)
Change-Id: Ic315b7a2c83e1f7203cd2a50e5d21a822e18fdca
Reviewed-on: https://go-review.googlesource.com/2097
Reviewed-by: Russ Cox <rsc@golang.org>
This implements support for calls to and from C in the ppc64 C ABI, as
well as supporting functionality such as an entry point from the
dynamic linker.
Change-Id: I68da6df50d5638cb1a3d3fef773fb412d7bf631a
Reviewed-on: https://go-review.googlesource.com/2009
Reviewed-by: Russ Cox <rsc@golang.org>
Cgo will need this for calls from C to Go and for handling signals
that may occur in C code.
Change-Id: I50cc4caf17cd142bff501e7180a1e27721463ada
Reviewed-on: https://go-review.googlesource.com/2008
Reviewed-by: Russ Cox <rsc@golang.org>
R13 is the C TLS pointer. Once we're calling to and from C code, if
we clobber R13 in our code, sigtramp won't know whether to get the
current g from REGG or from C TLS. The simplest solution is for Go
code to preserve the C TLS pointer. This is equivalent to what other
platforms do, except that on other platforms the TLS pointer is in a
special register.
Change-Id: I076e9cb83fd78843eb68cb07c748c4705c9a4c82
Reviewed-on: https://go-review.googlesource.com/2007
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This implements the ELF relocations and dynamic linking tables
necessary to support internal linking on ppc64. It also marks ppc64le
ELF files as ABI v2; failing to do this doesn't seem to confuse the
loader, but it does confuse libbfd (and hence gdb, objdump, etc).
Change-Id: I559dddf89b39052e1b6288a4dd5e72693b5355e4
Reviewed-on: https://go-review.googlesource.com/2006
Reviewed-by: Russ Cox <rsc@golang.org>
Most ppc64 relocations come in six or more variants where the basic
relocation formula is the same, but which bits of the computed value
are installed where changes. Introduce the concept of "variants" for
internal relocations to support this. Since this applies to
architecture-independent relocation types like R_PCREL, we do this in
relocsym.
Currently there is only an identity variant. A later CL that adds
support for ppc64 ELF relocations will introduce more.
Change-Id: I0c5f0e7dbe5beece79cd24fe36267d37c52f1a0c
Reviewed-on: https://go-review.googlesource.com/2005
Reviewed-by: Russ Cox <rsc@golang.org>
ppc64 function symbols have both a global entry point and a local
entry point, where the difference is stashed in sym.other. We'll need
this information to generate calls to ELF ABI functions.
Change-Id: Ibe343923f56801de7ebec29946c79690a9ffde57
Reviewed-on: https://go-review.googlesource.com/2002
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Cache 2KB, 4KB, 8KB, and 16KB stacks. Larger stacks
will be allocated directly. There is no point in cacheing
32KB+ stacks as we ask for and return 32KB at a time
from the allocator.
Note that the minimum stack is 8K on windows/64bit and 4K on
windows/32bit and plan9. For these os/arch combinations,
the number of stack orders is less so that we have the same
maximum cached size.
Fixes#9045
Change-Id: Ia4195dd1858fb79fc0e6a91ae29c374d28839e44
Reviewed-on: https://go-review.googlesource.com/2098
Reviewed-by: Russ Cox <rsc@golang.org>
The ones at the end of M and G are just used to compute
their size for use in assembly. Generate the size explicitly.
The one at the end of itab is variable-sized, and at least one.
The ones at the end of interfacetype and uncommontype are not
needed, as the preceding slice references them (the slice was
originally added for use by reflect?).
The one at the end of stackmap is already accessed correctly,
and the runtime never allocates one.
Update #9401
Change-Id: Ia75e3aaee38425f038c506868a17105bd64c712f
Reviewed-on: https://go-review.googlesource.com/2420
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Fold in some startup randomness to make the hash vary across
different runs. This helps prevent attackers from choosing
keys that all map to the same bucket.
Also, reorganize the hash a bit. Move the *m1 multiply to after
the xor of the current hash and the message. For hash quality
it doesn't really matter, but for DDOS resistance it helps a lot
(any processing done to the message before it is merged with the
random seed is useless, as it is easily inverted by an attacker).
Update #9365
Change-Id: Ib19968168e1bbc541d1d28be2701bb83e53f1e24
Reviewed-on: https://go-review.googlesource.com/2344
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The gc toolchain no longer includes a C compiler, so mentions of "6c"
can be removed or replaced by 6g as appropriate. Similarly, some cgo
functions that previously generated C source output no longer need to.
Change-Id: I1ae6b02630cff9eaadeae6f3176c0c7824e8fbe5
Reviewed-on: https://go-review.googlesource.com/2391
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reader.Discard is the complement to Peek. It discards the next n bytes
of input.
We already have Reader.Buffered to see how many bytes of data are
sitting available in memory, and Reader.Peek to get that that buffer
directly. But once you're done with the Peek'd data, you can't get rid
of it, other than Reading it.
Both Read and io.CopyN(ioutil.Discard, bufReader, N) are relatively
slow. People instead resort to multiple blind ReadByte calls, just to
advance the internal b.r variable.
I've wanted this previously, several people have asked for it in the
past on golang-nuts/dev, and somebody just asked me for it again in a
private email. There are a few places in the standard library we'd use
it too.
Change-Id: I85dfad47704a58bd42f6867adbc9e4e1792bc3b0
Reviewed-on: https://go-review.googlesource.com/2260
Reviewed-by: Russ Cox <rsc@golang.org>
This CL only fixes the build, there are two failing tests:
RaceMapBigValAccess1 and RaceMapBigValAccess2
in runtime/race tests. I haven't investigated why yet.
Updates #9516.
Change-Id: If5bd2f0bee1ee45b1977990ab71e2917aada505f
Reviewed-on: https://go-review.googlesource.com/2401
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Use direct binary insertion instead of recursive calls to symMerge
when one of the blocks has only one element.
benchmark old ns/op new ns/op delta
BenchmarkStableString1K 421999 397629 -5.77%
BenchmarkStableInt1K 123422 120592 -2.29%
BenchmarkStableInt64K 9629094 9620200 -0.09%
BenchmarkStable1e2 123089 120209 -2.34%
BenchmarkStable1e4 39505228 36870029 -6.67%
BenchmarkStable1e6 8196612367 7630840157 -6.90%
Change-Id: I49905a909e8595cfa05920ccf9aa00a8f3036110
Reviewed-on: https://go-review.googlesource.com/2219
Reviewed-by: Robert Griesemer <gri@golang.org>
sysReserve doesn't actually reserve the full amount requested on
64-bit systems, because of problems with ulimit. Instead it checks
that it can get the first 64 kB and assumes it can grab the rest as
needed. This doesn't work well with the "let the kernel pick an address"
mode, so don't do that. Pick a high address instead.
Change-Id: I4de143a0e6fdeb467fa6ecf63dcd0c1c1618a31c
Reviewed-on: https://go-review.googlesource.com/2345
Reviewed-by: Rick Hudson <rlh@golang.org>
The line 'mp.schedlink = mnext' has an implicit write barrier call,
which needs a valid g. Move it above the setg(nil).
Change-Id: If3e86c948e856e10032ad89f038bf569659300e0
Reviewed-on: https://go-review.googlesource.com/2347
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
This test is doing pointer graph manipulation from C, and we
cannot support that with concurrent GC. The wbshadow mode
correctly diagnoses missing write barriers.
Disable the test in that mode for now. There is a bigger issue
behind it, namely SWIG, but for now we are focused on making
all.bash pass with wbshadow enabled.
Change-Id: I55891596d4c763e39b74082191d4a5fac7161642
Reviewed-on: https://go-review.googlesource.com/2346
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
There are two methods by which TLS clients signal the renegotiation
extension: either a special cipher suite value or a TLS extension.
It appears that I left debugging code in when I landed support for the
extension because there's a "+ 1" in the switch statement that shouldn't
be there.
The effect of this is very small, but it will break Firefox if
security.ssl.require_safe_negotiation is enabled in about:config.
(Although almost nobody does this.)
This change fixes the original bug and adds a test. Sadly the test is a
little complex because there's no OpenSSL s_client option that mirrors
that behaviour of require_safe_negotiation.
Change-Id: Ia6925c7d9bbc0713e7104228a57d2d61d537c07a
Reviewed-on: https://go-review.googlesource.com/1900
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
SignPSS is documented as allowing opts to be nil, but actually
crashes in that case. This change fixes that.
Change-Id: Ic48ff5f698c010a336e2bf720e0f44be1aecafa0
Reviewed-on: https://go-review.googlesource.com/2330
Reviewed-by: Minux Ma <minux@golang.org>
First, call clearcheckmarks immediately after changing checkmark,
so that there is less time when the checkmark flag and the bitmap
are inconsistent. The tiny gap between the two lines is fine, because
the world is stopped. Before, the gap was much larger and included
such code as "go bgsweep()", which allocated.
Second, modify gcphase only when the world is stopped.
As written, gcscan_m was changing gcphase from 0 to GCscan
and back to 0 while other goroutines were running.
Another goroutine running at the same time might decide to
sleep, see GCscan, call gcphasework, and start "helping" by
scanning its stack. That's fine, except that if gcphase flips back
to 0 as the goroutine calls scanblock, it will start draining the
work buffers prematurely.
Both of these were found wbshadow=2 (and a lot of hard work).
Eventually that will run automatically, but right now it still
doesn't quite work for all.bash, due to mmap conflicts with
pthread-created threads.
Change-Id: I99aa8210cff9c6e7d0a1b62c75be32a23321897b
Reviewed-on: https://go-review.googlesource.com/2340
Reviewed-by: Rick Hudson <rlh@golang.org>
Found with GODEBUG=wbshadow=2 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: I5624b509a36650bce6834cf394b9da163abbf8c0
Reviewed-on: https://go-review.googlesource.com/2310
Reviewed-by: Rick Hudson <rlh@golang.org>
Use typedmemmove, typedslicecopy, and adjust reflect.call
to execute the necessary write barriers.
Found with GODEBUG=wbshadow=2 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: Iec5b5b0c1be5589295e28e5228e37f1a92e07742
Reviewed-on: https://go-review.googlesource.com/2312
Reviewed-by: Keith Randall <khr@golang.org>
These depend on storing arbitrary integer values using
pointer atomics, and we can't support that anymore.
Change-Id: I8cadd6d462c3eebdbe7078f43fe7c779fa8f52b3
Reviewed-on: https://go-review.googlesource.com/2311
Reviewed-by: Rick Hudson <rlh@golang.org>
A side effect of this change is that when assertI2T writes to the
memory for the T being extracted, it can use typedmemmove
for write barriers.
There are other ways we could have done this, but this one
finishes a TODO in package runtime.
Found with GODEBUG=wbshadow=2 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: Icbc8aabfd8a9b1f00be2e421af0e3b29fa54d01e
Reviewed-on: https://go-review.googlesource.com/2279
Reviewed-by: Keith Randall <khr@golang.org>
Found with GODEBUG=wbshadow=2 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: I1320d5340a9e421c779f24f3b170e33974e56e4f
Reviewed-on: https://go-review.googlesource.com/2278
Reviewed-by: Rick Hudson <rlh@golang.org>
Found with GODEBUG=wbshadow=2 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: Iea83d693480c2f3008b4e80d55821acff65970a6
Reviewed-on: https://go-review.googlesource.com/2277
Reviewed-by: Keith Randall <khr@golang.org>
Preparation for replacing many memmove calls in runtime
with typedmemmove, which is a clearer description of what
the routine is doing.
For the same reason, rename writebarriercopy to typedslicecopy.
Change-Id: I6f23bef2c2215509fefba175b16908f76dc7538c
Reviewed-on: https://go-review.googlesource.com/2276
Reviewed-by: Rick Hudson <rlh@golang.org>
Add write barrier to atomic operations manipulating pointers.
In general an atomic write of a pointer word may indicate racy accesses,
so there is no strictly safe way to attempt to keep the shadow copy
in sync with the real one. Instead, mark the shadow copy as not used.
Redirect sync/atomic pointer routines back to the runtime ones,
so that there is only one copy of the write barrier and shadow logic.
In time we might consider doing this for most of the sync/atomic
functions, but for now only the pointer routines need that treatment.
Found with GODEBUG=wbshadow=1 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: I852936b9a111a6cb9079cfaf6bd78b43016c0242
Reviewed-on: https://go-review.googlesource.com/2066
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The Gobuf.g goroutine pointer is almost always updated by assembly code.
In one of the few places it is updated by Go code - func save - it must be
treated as a uintptr to avoid a write barrier being emitted at a bad time.
Instead of figuring out how to emit the write barriers missing in the
assembly manipulation, change the type of the field to uintptr, so that
it does not require write barriers at all.
Goroutine structs are published in the allg list and never freed.
That will keep the goroutine structs from being collected.
There is never a time that Gobuf.g's contain the only references
to a goroutine: the publishing of the goroutine in allg comes first.
Goroutine pointers are also kept in non-GC-visible places like TLS,
so I can't see them ever moving. If we did want to start moving data
in the GC, we'd need to allocate the goroutine structs from an
alternate arena. This CL doesn't make that problem any worse.
Found with GODEBUG=wbshadow=1 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: I85f91312ec3e0ef69ead0fff1a560b0cfb095e1a
Reviewed-on: https://go-review.googlesource.com/2065
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Found with GODEBUG=wbshadow=1 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: Ic8624401d7c8225a935f719f96f2675c6f5c0d7c
Reviewed-on: https://go-review.googlesource.com/2064
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This is the detection code. It works well enough that I know of
a handful of missing write barriers. However, those are subtle
enough that I'll address them in separate followup CLs.
GODEBUG=wbshadow=1 checks for a write that bypassed the
write barrier at the next write barrier of the same word.
If a bug can be detected in this mode it is typically easy to
understand, since the crash says quite clearly what kind of
word has missed a write barrier.
GODEBUG=wbshadow=2 adds a check of the write barrier
shadow copy during garbage collection. Bugs detected at
garbage collection can be difficult to understand, because
there is no context for what the found word means.
Typically you have to reproduce the problem with allocfreetrace=1
in order to understand the type of the badly updated word.
Change-Id: If863837308e7c50d96b5bdc7d65af4969bf53a6e
Reviewed-on: https://go-review.googlesource.com/2061
Reviewed-by: Austin Clements <austin@google.com>
When constants were declared using unexported constants,
the type information was lost when those constants were filtered out.
This CL propagates the type information of unexported constants
so that it is available for display.
This is a follow-up to CL 144110044, which fixed this problem
specifically for _ constants.
Updates #5397.
Change-Id: I3f0c767a4007d88169a5634ab2870deea4e6a740
Reviewed-on: https://go-review.googlesource.com/2091
Reviewed-by: Robert Griesemer <gri@golang.org>
Noticed while investigating the speed of the runtime tests, as part
of debugging while Plan 9's runtime tests are timing out on GCE.
Change-Id: I95f5a3d967a0b45ec1ebf10067e193f51db84e26
Reviewed-on: https://go-review.googlesource.com/2283
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The existing go code document did not link to the GOPATH documentation.
This will link to it, in hopes of making it more discoverable.
Change-Id: Ie4ded2fdce08f412e4acbcc93acdd76f5791b84a
Reviewed-on: https://go-review.googlesource.com/2265
Reviewed-by: Andrew Gerrand <adg@golang.org>
This reverts commit ab0535ae3f.
I think it will remain useful to distinguish code that must
run on a system stack from code that can run on either stack,
even if that distinction is no
longer based on the implementation language.
That is, I expect to add a //go:systemstack comment that,
in terms of the old implementation, tells the compiler,
to pretend this function was written in C.
Change-Id: I33d2ebb2f99ae12496484c6ec8ed07233d693275
Reviewed-on: https://go-review.googlesource.com/2275
Reviewed-by: Russ Cox <rsc@golang.org>
This CL splits the (ever growing) list of ca cert locations by major unix
platforms (darwin, windows and plan9 are already handled seperately).
Although it is clear the unix variants cannot manage to agree on some standard
locations, we can avoid to some extent an artificial ranking of priority
amongst the supported GOOSs.
* Split certFiles definition by GOOS
* Include NetBSD ca cert location
Fixes#9285
Change-Id: I6df2a3fddf3866e71033e01fce43c31e51b48a9e
Reviewed-on: https://go-review.googlesource.com/2208
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
This ensures that changing an image.YCbCr's Y values can't change its
chroma values, even after re-slicing up to capacity.
Change-Id: Icb626561522e336a3220e10f456c95330ae7db9e
Reviewed-on: https://go-review.googlesource.com/2209
Reviewed-by: Rob Pike <r@golang.org>
Previously, we ended up passing two compiled objects for the package
being tested when linking the test executable. Somewhat by luck, this
worked most of the time but occasionally it did not. This changes the
linking code to not pass two objects for the same ImportPath and to
always pass the object for the test version of the package and removes
some unecessary nil checks.
Change-Id: I7bbd3fc708f14672ee2cc6aed3397421fceb8a38
Reviewed-on: https://go-review.googlesource.com/1840
Reviewed-by: Ian Lance Taylor <iant@golang.org>
liblink used to encode both SETEQ BP and SETEQ CH as 0f 94 c5,
however, SETEQ BP should have used a REX prefix.
Fixes#8545.
Change-Id: Ie59c990cdd0ec506cffe4318e9ad1b48db5e57dd
Reviewed-on: https://go-review.googlesource.com/2270
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This CL adds missing ipv4-mapped ipv6 address test cases to TestParseIP.
Change-Id: I3144d2a88d409bd515cf52f8711d407bfa81ed68
Reviewed-on: https://go-review.googlesource.com/2205
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Shell out to `uname -r` this time, so that the test will compile
even if the platform doesn't have syscall.Sysctl.
Change-Id: I3a19ab5d820bdb94586a97f4507b3837d7040525
Reviewed-on: https://go-review.googlesource.com/2271
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The test program requires static constructor, which in turn needs
external linking to work, but external linking never works on 10.6.
This should fix the darwin-{386,amd64} builders.
Change-Id: I714fdd3e35f9a7e5f5659cf26367feec9412444f
Reviewed-on: https://go-review.googlesource.com/2235
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Mostly I need to tickle the builders, since I'm working on the
dashboard builders right now.
Change-Id: I833fc22bc942758a58791ed038634cdd812f5411
Reviewed-on: https://go-review.googlesource.com/2261
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If the user provided a key but no value via -ldflag -X,
another linker flag was used as the value.
Placing the user's flags at the end avoids this problem.
It also provides the user the opportunity to
override existing linker flags.
Fixes#8810.
Change-Id: I96f4190713dc9a9c29142e56658446fba7fb6bc8
Reviewed-on: https://go-review.googlesource.com/2242
Reviewed-by: Minux Ma <minux@golang.org>
Remove use of itod on posix systems and replace with call to itoa.
Build and use same itoa function on all systems.
Fix infinite recursion in iota function for the case -1<<63.
Change-Id: I89d7e742383c5c4aeef8780501c78a3e1af87a6f
Reviewed-on: https://go-review.googlesource.com/2213
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Updated the issue tracker link the compiler prints out
when asking for a bug report after an internal error.
Change-Id: I092b118130f131c6344d9d058bea4ad6379032b8
Reviewed-on: https://go-review.googlesource.com/2218
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Our definition of struct timespec used to cause problems with
certain versions of mingw-rt. However, as it turns out, we don't
actually need those definitions and prototypes, so remove them.
Fixes#9472.
Change-Id: Ie0880f0d58be112625140f73d0bed71f98b7cf05
Reviewed-on: https://go-review.googlesource.com/2236
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Preventing returning io.EOF on non-connection oriented sockets is
already applied to Unix variants. This CL applies it to Windows.
Update #4856.
Change-Id: I82071d40f617e2962d0540b9d1d6a10ea4cdb2ec
Reviewed-on: https://go-review.googlesource.com/2203
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
There is no reason to have the redundant test case TestDNSThreadLimt
because TestLookupIPDeadline does cover what we need to test with
-dnsflood flag and more.
Also this CL moves TestLookupIPDeadline into lookup_test.go to avoid
abusing to control the order of test case execution by using file name.
Change-Id: Ib417d7d3411c59d9352c03c996704d584368dc62
Reviewed-on: https://go-review.googlesource.com/2204
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I missed this one in golang.org/cl/2232 and only tested the patch
on openbsd/amd64.
Change-Id: I4ff437ae0bfc61c989896c01904b6d33f9bdf0ec
Reviewed-on: https://go-review.googlesource.com/2234
Reviewed-by: Minux Ma <minux@golang.org>
This is a genuine bug exposed by our test for issue 9456: our wrapper
for pthread_create is not initialized until we initialize cgo itself,
but it is possible that a static constructor could call pthread_create,
and in that case, it will be calling a nil function pointer.
Fix that by also initializing the sys_pthread_create function pointer
inside our pthread_create wrapper function, and use a pthread_once to
make sure it is only initialized once.
Fix build for openbsd.
Change-Id: Ica4da2c21fcaec186fdd3379128ef46f0e767ed7
Reviewed-on: https://go-review.googlesource.com/2232
Reviewed-by: David Crawshaw <crawshaw@golang.org>
%lL will prepend the current directory to the filename, which is not
what we want here (as the file name is already absolute).
Fixes#9150.
Change-Id: I4c9386be6baf421393b92d9401a264b4692986d0
Reviewed-on: https://go-review.googlesource.com/2231
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some libraries, for example, OpenBLAS, create work threads in a global constructor.
If we're doing cpu profiling, it's possible that SIGPROF might come to some of the
worker threads before we make our first cgo call. Cgocallback used to terminate the
process when that happens, but it's better to miss a couple profiling signals than
to abort in this case.
Fixes#9456.
Change-Id: I112b8e1a6e10e6cc8ac695a4b518c0f577309b6b
Reviewed-on: https://go-review.googlesource.com/2141
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Avoid the decimal lookup in digits array and compute the decimal character value directly.
Reduce calls to 64bit division on 32bit plattforms by splitting conversion into smaller blocks.
Convert value to uintptr type when it can be represented by uintptr.
on darwin/386
benchmark old ns/op new ns/op delta
BenchmarkFormatInt 8352 7466 -10.61%
BenchmarkAppendInt 4281 3401 -20.56%
BenchmarkFormatUint 2785 2251 -19.17%
BenchmarkAppendUint 1770 1223 -30.90%
on darwin/amd64
benchmark old ns/op new ns/op delta
BenchmarkFormatInt 5531 5492 -0.71%
BenchmarkAppendInt 2435 2295 -5.75%
BenchmarkFormatUint 1628 1569 -3.62%
BenchmarkAppendUint 726 750 +3.31%
Change-Id: Ifca281cbdd62ab7d7bd4b077a96da99eb12cf209
Reviewed-on: https://go-review.googlesource.com/2105
Reviewed-by: Robert Griesemer <gri@golang.org>
We already had client support for trailers, but no way for a server to
set them short of hijacking the connection.
Fixes#7759
Change-Id: Ic83976437739ec6c1acad5f209ed45e501dbb93a
Reviewed-on: https://go-review.googlesource.com/2157
Reviewed-by: Andrew Gerrand <adg@golang.org>
Following change 2154, the goatoi function
was renamed atoi.
However, this definition conflicts with the
atoi function defined in the Plan 9 runtime,
which takes a []byte instead of a string.
This change fixes the build on Plan 9.
Change-Id: Ia0f7ca2f965bd5e3cce3177bba9c806f64db05eb
Reviewed-on: https://go-review.googlesource.com/2165
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
They are no longer needed now that C is gone.
goatoi -> atoi
gofuncname/funcname -> funcname/cfuncname
goroundupsize -> already existing roundupsize
Change-Id: I278bc33d279e1fdc5e8a2a04e961c4c1573b28c7
Reviewed-on: https://go-review.googlesource.com/2154
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Now that we've removed all the C code in runtime and the C compilers,
there is no need to have a separate stackguard field to check for C
code on Go stack.
Remove field g.stackguard1 and rename g.stackguard0 to g.stackguard.
Adjust liblink and cmd/ld as necessary.
Change-Id: I54e75db5a93d783e86af5ff1a6cd497d669d8d33
Reviewed-on: https://go-review.googlesource.com/2144
Reviewed-by: Keith Randall <khr@golang.org>
The goalg function was a holdover from when we had algorithm
tables in both C and Go. It is no longer needed.
Change-Id: Ia0c1af35bef3497a899f22084a1a7b42daae72a0
Reviewed-on: https://go-review.googlesource.com/2099
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The error message for decoding a unquoted value into a struct field with
the ,string option specified has two arguments when one is needed.
Make the error message take one argument and add a test in order to cover
the case when a unquoted value is specified.
Also add error value as the missing argument for Fatalf call in test.
Fixes the following go vet reports:
decode.go:602: wrong number of args for format in Errorf call: 1 needed but 2 args
decode_test.go:1088: missing argument for Fatalf("%v"): format reads arg 1, have only 0 args
Change-Id: Id036e10c54c4a7c1ee9952f6910858ecc2b84134
Reviewed-on: https://go-review.googlesource.com/2109
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Rename "gothrow" to "throw" now that the C version of "throw"
is no longer needed.
This change is purely mechanical except in panic.go where the
old version of "throw" has been deleted.
sed -i "" 's/[[:<:]]gothrow[[:>:]]/throw/g' runtime/*.go
Change-Id: Icf0752299c35958b92870a97111c67bcd9159dc3
Reviewed-on: https://go-review.googlesource.com/2150
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
The new test case produces the longest string representation possible and thereby uses
all of the 65 bytes in the buffer array used by the formatBits function.
Change-Id: I11320c4de56ced5ff098b7e37f1be08e456573e2
Reviewed-on: https://go-review.googlesource.com/2108
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently we do very a complex rebalancing of runnable goroutines
between queues, which tries to preserve scheduling fairness.
Besides being complex and error-prone, it also destroys all locality
of scheduling.
This change uses simpler scheme: leave runnable goroutines where
they are, during starttheworld start all Ps with local work,
plus start one additional P in case we have excessive runnable
goroutines in local queues or in the global queue.
The schedler must be able to operate efficiently w/o the rebalancing,
because garbage collections do not have to happen frequently.
The immediate need is execution tracing support: handling of
garabage collection which does stoptheworld/starttheworld several
times becomes exceedingly complex if the current execution can
jump between Ps during starttheworld.
Change-Id: I4fdb7a6d80ca4bd08900d0c6a0a252a95b1a2c90
Reviewed-on: https://go-review.googlesource.com/1951
Reviewed-by: Rick Hudson <rlh@golang.org>
This test code is ugly. There must be a better way.
But for now, fix the build.
Change-Id: I33064145ea37f11abf040ec97caa87669be1a9fa
Reviewed-on: https://go-review.googlesource.com/2114
Reviewed-by: Ian Lance Taylor <iant@golang.org>
numCanOpen will never be larger than 0 in maybeOpenNewConnections() when this
code path is taken, so no new connections can ever be opened.
Change-Id: Id1302e8d9afb3a67be61b5e738fe07ef81d20fe0
Reviewed-on: https://go-review.googlesource.com/1550
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For Go 1.5, we can use go:linkname rather than assembly thunk for gc.
Gccgo already has support for //extern.
Change-Id: I5505aa247dd5b555112f7261ed2f192c81cf0bdf
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/1888
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Move the checks for empty rotate changes
from the beginning of rotate to the callers.
Remove additional variable p used instead of existing m with same value.
Remove special casing of equal ranges (i==j) to exit early as no
work is saved vs checking (i!=j) and making a single
swapRange call if this is false.
benchmark old ns/op new ns/op delta
BenchmarkStableString1K 417195 425218 +1.92%
BenchmarkStableInt1K 126661 124498 -1.71%
BenchmarkStableInt64K 10365014 10417438 +0.51%
BenchmarkStable1e2 132151 130648 -1.14%
BenchmarkStable1e4 42027428 40812649 -2.89%
BenchmarkStable1e6 8524772364 8430192391 -1.11%
Change-Id: Ia7642e9d31408496970c700f5843d53cc3ebe817
Reviewed-on: https://go-review.googlesource.com/2100
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When go parses #cgo lines, expand ${SRCDIR} into the path to the
source directory. This allows options to be passed to the
compiler and linker that involve file paths relative to the
source code directory. Without the expansion the paths would be
invalid when the current working directory changes.
Fixes#7891Fixes#5428
Change-Id: I343a145a9771a5ccbaa958e4a1ecd1716fcae52d
Reviewed-on: https://go-review.googlesource.com/1756
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Test more stuff:
1) flagNoPointers, an incorrect value was the cause of #9425
2) Total function layout size
3) gc program
Change-Id: I73f65fe740215938fa930d2f096febd9db0a0021
Reviewed-on: https://go-review.googlesource.com/2090
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The code concerning quoted-printable encoding (RFC 2045) and its
variant for MIME headers (RFC 2047) is currently spread in
mime/multipart and net/mail. It is also not exported.
This commit is the first step to fix that issue. It moves the
quoted-printable decoding code from mime/multipart to
mime/internal/quotedprintable. The exposed API is unchanged.
Concerns #4943.
Change-Id: I11352afbb2edb4d6ef62870b9bc5c87c639eff12
Reviewed-on: https://go-review.googlesource.com/1810
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add a nil byte at the end of the itoa buffer,
before calling gostringnocopy. This prevents
gostringnocopy to read past the buffer size.
Change-Id: I87494a8dd6ea45263882536bf6c0f294eda6866d
Reviewed-on: https://go-review.googlesource.com/2033
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Originally it used r.Int63() to show "Uint32", and now we use the correct r.Uint32() method.
Fixes#9429
Change-Id: I8a1228f1ca1af93b0e3104676fc99000257c456f
Reviewed-on: https://go-review.googlesource.com/2069
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
These tests were enabled as part of change 1774.
They depend on the errchk tool, which is a Perl
script. However, Perl is not available on Plan 9.
Change-Id: I82707aae16013acc9a3800d39b0084588b852b53
Reviewed-on: https://go-review.googlesource.com/2031
Reviewed-by: Minux Ma <minux@golang.org>
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>
issue9400_linux.go did not build on 386 because it used a constant
that was larger than a 32-bit int in a ... argument. Fix this by
casting the constant to uint64 (to match how the constant is being
used).
Change-Id: Ie8cb64c3910382a41c7852be7734a62f0b2d5a21
Reviewed-on: https://go-review.googlesource.com/2060
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
Broken by e7173dfdfd
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/2052
Reviewed-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/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>
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/1690
Reviewed-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/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>
* 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/1774
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>
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>
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/1904
Reviewed-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/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>
This test was added in CL 151000043.
It got lost in CL 144630044.
Change-Id: I318ab11be8e3e7489fc1395457c029c8bdb2aa41
Reviewed-on: https://go-review.googlesource.com/1773
Reviewed-by: Ian Lance Taylor <iant@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>
Gccgo incorrectly executed functions multiple times when they appeared
in a composite literal that required a conversion between different
interface types.
Change-Id: I7b40e76ed23fa8440ffa03b262041265c109adf7
Reviewed-on: https://go-review.googlesource.com/1710
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Gccgo failed to create the type descriptor for the type used to
allocate the nil value passed to append as the second argument when
append is called with only one argument. Calling append with only one
argument is unusual but obviously should not cause a compiler crash.
Change-Id: I530821847dfd68f0302de6ca6a84dfbc79653935
Reviewed-on: https://go-review.googlesource.com/1692
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@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
These are the references that affect current Go users.
I left intact references in older release notes;
we can figure out what to do with them later.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/186140043
Conflicts:
doc/go1.4.html
Change-Id: I1032686f2b3ac6dacaf8f114b8c35cdf221330ca
Also: checkout sub-repos from Mercurial manually
instead of using "go get". (for the 1.4 release)
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/190720043
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>
Make sure dequeueing from a channel queue does not exhibit quadratic time behavior.
Change-Id: Ifb7c709b026f74c7e783610d4914dd92909a441b
Reviewed-on: https://go-review.googlesource.com/1212
Reviewed-by: Russ Cox <rsc@golang.org>
Usage:
fibo <n> compute fibonacci(n), n must be >= 0
fibo -bench benchmark fibonacci computation (takes about 1 min)
Additional flags:
-half add values using two half-digit additions
-opt optimize memory allocation through reuse
-short only print the first 10 digits of very large fibonacci numbers
This change was reviewed in detail as https://codereview.appspot.com/168480043 .
Change-Id: I7c86d49c5508532ea6206d00f424cf2117d2fe41
Reviewed-on: https://go-review.googlesource.com/1211
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
640 bytes ought to be enough for anybody.
We'll bring this back down before Go 1.5. That's issue 9214.
TBR=rlh
CC=golang-codereviews
https://golang.org/cl/188730043
This is going to hurt a bit but we'll make it better later.
Now the race detector can be run again.
I added the write barrier optimizations from
CL 183020043 to try to make it hurt a little less.
TBR=rlh
CC=golang-codereviews
https://golang.org/cl/185070043
This is the last system-dependent file written by cmd/dist.
They are all now written by go generate.
cmd/dist is not needed to start building package runtime
for a different system anymore.
Now all the generated files can be assumed generated, so
delete the clumsy hacks in cmd/api.
Re-enable api check in run.bash.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/185040044
With this change, default now contains Go 1.5 work.
Any future bug fixes for Go 1.4 in the compilers or
the runtime will have to be made directly to the
release branch.
When liblink sees something like
JMP x
...
x: JMP y
it rewrites the first jump to jump directly to y. This is
fine if y is a resolved label. However, it *also* does this
if y is a function symbol, but fails to carry over the
relocation that would later patch in that symbol's value. As
a result, the original jump becomes either a self-jump (if
relative) or a jump to PC 0 (if absolute).
Fix this by disabling this optimization if the jump being
patched in is a jump to a symbol.
LGTM=minux
R=rsc, minux
CC=golang-codereviews
https://golang.org/cl/185890044
Frankly, I don't understand how the current code could possibly work except
when every android program is using cgo. Discovered this while working on
the iOS port.
LGTM=crawshaw, rsc
R=rsc, crawshaw
CC=golang-codereviews
https://golang.org/cl/177470043
The new semantics of split require the newline be present.
The test was stale.
LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/182480043
Scanner can't handle stupid long lines and there are
reports of stupid long lines in production.
Note the issue isn't long "//go:generate" lines, but
any long line in any Go source file.
To be fair, if you're going to have a stupid long line
it's not a bad bet you'll want to run it through go
generate, because it's some embeddable asset that
has been machine generated. (One could ask why
that generation process didn't add a newline or two,
but we should cope anyway.)
Rewrite the file scanner in "go generate" so it can
handle arbitrarily long lines, and only stores in memory
those lines that start "//go:generate".
Also: Adjust the documentation to make clear that it
does not parse the file.
Fixes#9143.
Fixes#9196.
LGTM=rsc, dominik.honnef
R=rsc, cespare, minux, dominik.honnef
CC=golang-codereviews
https://golang.org/cl/182970043
While we're at there, also add a message to prompt the user to install
Graphviz if "dot" command is not found.
Fixes#9178.
LGTM=adg, alex.brainman, cookieo9, rsc
R=rsc, adg, bradfitz, alex.brainman, cookieo9, smyrman
CC=golang-codereviews
https://golang.org/cl/180380043
Move change from CL 170770043 to correct file and regenerate docs
for changes from CL 164120043.
LGTM=adg
R=golang-codereviews, adg, bradfitz
CC=golang-codereviews
https://golang.org/cl/183000043
During garbage collection, after scanning a stack, we think about
shrinking it to reclaim some memory. The shrinking code (called
while the world is stopped) checked that the status was Gwaiting
or Grunnable and then changed the state to Gcopystack, to essentially
lock the stack so that no other GC thread is scanning it.
The same locking happens for stack growth (and is more necessary there).
oldstatus = runtime·readgstatus(gp);
oldstatus &= ~Gscan;
if(oldstatus == Gwaiting || oldstatus == Grunnable)
runtime·casgstatus(gp, oldstatus, Gcopystack); // oldstatus is Gwaiting or Grunnable
else
runtime·throw("copystack: bad status, not Gwaiting or Grunnable");
Unfortunately, "stop the world" doesn't stop everything. It stops all
normal goroutine execution, but the network polling thread is still
blocked in epoll and may wake up. If it does, and it chooses a goroutine
to mark runnable, and that goroutine is the one whose stack is shrinking,
then it can happen that between readgstatus and casgstatus, the status
changes from Gwaiting to Grunnable.
casgstatus assumes that if the status is not what is expected, it is a
transient change (like from Gwaiting to Gscanwaiting and back, or like
from Gwaiting to Gcopystack and back), and it loops until the status
has been restored to the expected value. In this case, the status has
changed semi-permanently from Gwaiting to Grunnable - it won't
change again until the GC is done and the world can continue, but the
GC is waiting for the status to change back. This wedges the program.
To fix, call a special variant of casgstatus that accepts either Gwaiting
or Grunnable as valid statuses.
Without the fix bug with the extra check+throw in casgstatus, the
program below dies in a few seconds (2-10) with GOMAXPROCS=8
on a 2012 Retina MacBook Pro. With the fix, it runs for minutes
and minutes.
package main
import (
"io"
"log"
"net"
"runtime"
)
func main() {
const N = 100
for i := 0; i < N; i++ {
l, err := net.Listen("tcp", "127.0.0.1:0")
if err != nil {
log.Fatal(err)
}
ch := make(chan net.Conn, 1)
go func() {
var err error
c1, err := net.Dial("tcp", l.Addr().String())
if err != nil {
log.Fatal(err)
}
ch <- c1
}()
c2, err := l.Accept()
if err != nil {
log.Fatal(err)
}
c1 := <-ch
l.Close()
go netguy(c1, c2)
go netguy(c2, c1)
c1.Write(make([]byte, 100))
}
for {
runtime.GC()
}
}
func netguy(r, w net.Conn) {
buf := make([]byte, 100)
for {
bigstack(1000)
_, err := io.ReadFull(r, buf)
if err != nil {
log.Fatal(err)
}
w.Write(buf)
}
}
var g int
func bigstack(n int) {
var buf [100]byte
if n > 0 {
bigstack(n - 1)
}
g = int(buf[0]) + int(buf[99])
}
Fixes#9186.
LGTM=rlh
R=austin, rlh
CC=dvyukov, golang-codereviews, iant, khr, r
https://golang.org/cl/179680043
These accomplished the same thing, but R_CALLPOWER expected
the whole instruction to be in the addend (and completely
overwrote what was in the text section), while R_PPC64_REL24
overwrites only bits 6 through 24 of whatever was in the text
section. Make R_CALLPOWER work like R_PPC64_REL24 to ease the
implementation of dynamic linking.
LGTM=rsc
R=rsc
CC=golang-codereviews, minux
https://golang.org/cl/177430043
warning: src/cmd/5g/reg.c:461 format mismatch d VLONG, arg 5
warning: src/cmd/6g/reg.c:396 format mismatch d VLONG, arg 5
warning: src/cmd/9g/reg.c:440 format mismatch d VLONG, arg 5
LGTM=minux
R=rsc, minux
CC=golang-codereviews
https://golang.org/cl/179300043
This was based on the 9c peephole optimizer, modified to work
with code generated by gc and use the proginfo infrastructure
in gc.
LGTM=rsc
R=rsc, bradfitz, minux
CC=golang-codereviews
https://golang.org/cl/179190043
This adds some utilities for converting between the CC, V, and
VCC variants of operations and uses these to derive the
ProgInfo entries for these variants (which are identical to
the ProgInfo for the base operations).
The 9g peephole optimizer will also use these conversion
utilities.
LGTM=minux, rsc
R=rsc, dave, minux
CC=golang-codereviews
https://golang.org/cl/180110044
Otherwise both zgoos_linux.go and zgoos_android.go will be compiled
for GOOS=android.
LGTM=crawshaw, rsc
R=rsc, crawshaw
CC=golang-codereviews
https://golang.org/cl/178110043
We don't know what we need yet, so add them all.
Add them even on x86 architectures (as no-ops) so that
the GC can refer to them unconditionally.
Eventually we'll know what we want and probably
have just one 'prefetch' with an appropriate meaning
on each architecture.
LGTM=rlh
R=rlh
CC=golang-codereviews
https://golang.org/cl/179160043
warning: src/liblink/list6.c:94 set and not used: s
warning: src/liblink/list6.c:157 format mismatch ld VLONG, arg 3
warning: src/liblink/list6.c:157 format mismatch E UINT, arg 4
warning: src/liblink/list6.c:157 format mismatch d VLONG, arg 5
warning: src/liblink/list6.c:163 set and not used: s
warning: src/liblink/list9.c:105 set and not used: s
warning: src/liblink/list9.c:185 format mismatch ld VLONG, arg 3
warning: src/liblink/list9.c:185 format mismatch E UINT, arg 4
warning: src/liblink/list9.c:185 format mismatch d VLONG, arg 5
warning: src/liblink/list9.c:193 set and not used: s
LGTM=rsc
R=rsc
CC=austin, golang-codereviews, minux
https://golang.org/cl/176130043
Thanks to Aram Hăvărneanu, Nick Owens
and Russ Cox for the early reviews.
LGTM=aram, rsc
R=rsc, lucio.dere, aram, ality
CC=golang-codereviews, mischief
https://golang.org/cl/175370043
a->name and a->class are char, so Solaris doesn't like using
them as array indexes. (This same problem was fixed for amd64
in CL 169630043.)
LGTM=aram, minux
R=rsc, minux, aram
CC=golang-codereviews
https://golang.org/cl/175430043
Race detector runtime does not tolerate operations on addresses
that was not previously declared with __tsan_map_shadow
(namely, data, bss and heap). The corresponding address
checks for atomic operations were removed in
https://golang.org/cl/111310044
Restore these checks.
It's tricker than just not calling into race runtime,
because it is the race runtime that makes the atomic
operations themselves (if we do not call into race runtime
we skip the atomic operation itself as well). So instead we call
__tsan_go_ignore_sync_start/end around the atomic operation.
This forces race runtime to skip all other processing
except than doing the atomic operation itself.
Fixes#9136.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/179030043
The assumption can be violated by external linkers reordering them or
inserting non-Go sections in between them. I looked briefly at trying
to write out the _go_.o in external linking mode in a way that forced
the ordering, but no matter what there's no way to force Go's data
and Go's bss to be next to each other. If there is any data or bss from
non-Go objects, it's very likely to get stuck in between them.
Instead, rewrite the two places we know about that make the assumption.
I grepped for noptrdata to look for more and didn't find any.
The added race test (os/exec in external linking mode) fails without
the changes in the runtime. It crashes with an invalid pointer dereference.
Fixes#9133.
LGTM=dneil
R=dneil
CC=dvyukov, golang-codereviews, iant
https://golang.org/cl/179980043
struct siginfo_t's si_addr field is part of a union.
Previously, we represented this union in Go using an opaque
byte array and accessed the si_addr field using unsafe (and
wrong on 386 and arm!) pointer arithmetic. Since si_addr is
the only field we use from this union, this replaces the
opaque byte array with an explicit declaration of the si_addr
field and accesses it directly.
LGTM=minux, rsc
R=rsc, minux
CC=golang-codereviews
https://golang.org/cl/179970044
Previously, this used the top 8 bits of an instruction as a
sort-of opcode and ignored the top two bits of the relative
PC. This worked because these jumps are always negative and
never big enough for the top two bits of the relative PC (also
the bottom 2 bits of the sort-of opcode) to be anything other
than 0b11, but the code is confusing because it doesn't match
the actual structure of the instruction.
Instead, use the real 6 bit opcode and use all 24 bits of
relative PC.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/179960043
Breaks reading from stdin in parent after exec with SysProcAttr{Setpgid: true}.
package main
import (
"fmt"
"os"
"os/exec"
"syscall"
)
func main() {
cmd := exec.Command("true")
cmd.SysProcAttr = &syscall.SysProcAttr{Setpgid: true}
cmd.Run()
fmt.Printf("Hit enter:")
os.Stdin.Read(make([]byte, 100))
fmt.Printf("Bye\n")
}
In go1.3, I type enter at the prompt and the program exits.
With the CL being rolled back, the program wedges at the
prompt.
««« original CL description
syscall: SysProcAttr job control changes
Making the child's process group the foreground process group and
placing the child in a specific process group involves co-ordination
between the parent and child that must be done post-fork but pre-exec.
LGTM=iant
R=golang-codereviews, gobot, iant, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/131750044
»»»
LGTM=minux, dneil
R=dneil, minux
CC=golang-codereviews, iant, michael.p.macinnis
https://golang.org/cl/174450043
Previously, lfstack assumed Linux limited user space addresses
to 43 bits on Power64 based on a paper from 2001. It turns
out the limit is now 46 bits, so lfstack was truncating
pointers.
Raise the limit to 48 bits (for some future proofing and to
make it match amd64) and add a self-test that will fail in a
useful way if ever unpack(pack(x)) != x.
With this change, dev.cc passes all.bash on power64le.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/174430043
This is the power64 component of CL 174950043.
With this, dev.cc compiles on power64 and power64le and passes
most tests if GOGC=off (but crashes in go_bootstrap if GC is
on).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/175290043
Fix a constant conversion error. Add set_{sec,nsec} for
timespec and set_usec for timeval. Fix type of
sigaltstackt.ss_size.
LGTM=rsc
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/180840043
Previously, 9a was the only assembler that had a different
name for RET, causing unnecessary friction in simple files
that otherwise assembled on all architectures. Add RET so
these work on 9a.
This also renames "R30" to "g" to avoid unintentionally
clobbering g in assembly code. This parallels a change made
to 5a.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/178030043
Eventually I'd like almost everything cmd/dist generates
to be done with 'go generate' and checked in, to simplify
the bootstrap process. The only thing cmd/dist really needs
to do is write things like the current experiment info and
the current version.
This is a first step toward that. It replaces the _NaCl etc
constants with generated ones goos_nacl, goos_darwin,
goarch_386, and so on.
LGTM=dave, austin
R=austin, dave, bradfitz
CC=golang-codereviews, iant, r
https://golang.org/cl/174290043
getFunctionSource gathers five lines of "margin" around every
requested sample line. However, if this margin went past the
end of the source file, getFunctionSource would encounter an
io.EOF error and abort with this error, resulting in listings
like
(pprof) list main.main
ROUTINE ======================== main.main in ...
0 8.33s (flat, cum) 99.17% of Total
Error: EOF
(pprof)
Modify the error handling in getFunctionSource so io.EOF is
always considered non-fatal. If it reaches EOF, it simply
returns the lines it has.
LGTM=bradfitz
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/172600043
Turns out it *is* needed because the cmd/link tests expect to find their own files.
««« original CL description
misc/nacl: exclude cmd/link from the test zip.
It does not appear to be necessary, and cmd/link does not appear in release branches.
LGTM=rsc
R=adg, rsc
CC=golang-codereviews
https://golang.org/cl/176900044
»»»
TBR=rsc
R=adg, rsc
CC=golang-codereviews
https://golang.org/cl/175870045
It does not appear to be necessary, and cmd/link does not appear in release branches.
LGTM=rsc
R=adg, rsc
CC=golang-codereviews
https://golang.org/cl/176900044
debug/goobj is not ready to be published but it is
needed for the various binary-reading commands.
Move to cmd/internal/goobj.
(The Go 1.3 release branch deleted it, but that's not
an option anymore due to the command dependencies.
The API is still not vetted nor terribly well designed.)
LGTM=adg, dsymonds
R=adg, dsymonds
CC=golang-codereviews
https://golang.org/cl/174250043
This change works around the "out of fixed registers"
issue with the Plan 9 C compiler on 386, introduced by
the Bits change to uint64 in CL 169060043.
The purpose of this CL is to be able to properly
follow the conversion of the Plan 9 runtime to Go
on the Plan 9 builders.
This CL could be reverted once the Go compilers will
be converted to Go.
Thanks to Nick Owens for investigating this issue.
LGTM=rsc
R=rsc
CC=austin, golang-codereviews, mischief
https://golang.org/cl/177860043
The SudoG used to sit on the stack, so it was cheap to allocated
and didn't need to be cleaned up when finished.
For the conversion to Go, we had to move sudog off the stack
for a few reasons, so we added a cache of recently used sudogs
to keep allocation cheap. But we didn't add any of the necessary
cleanup before adding a SudoG to the new cache, and so the cached
SudoGs had stale pointers inside them that have caused all sorts
of awful, hard to debug problems.
CL 155760043 made sure SudoG.elem is cleaned up.
CL 150520043 made sure SudoG.selectdone is cleaned up.
This CL makes sure SudoG.next, SudoG.prev, and SudoG.waitlink
are cleaned up. I should have done this when I did the other two
fields; instead I wasted a week tracking down a leak they caused.
A dangling SudoG.waitlink can point into a sudogcache list that
has been "forgotten" in order to let the GC collect it, but that
dangling .waitlink keeps the list from being collected.
And then the list holding the SudoG with the dangling waitlink
can find itself in the same situation, and so on. We end up
with lists of lists of unusable SudoGs that are still linked into
the object graph and never collected (given the right mix of
non-trivial selects and non-channel synchronization).
More details in golang.org/issue/9110.
Fixes#9110.
LGTM=r
R=r
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/177870043
I just created that redirect, so we can change
it once the wiki moves.
LGTM=bradfitz, khr
R=khr, bradfitz
CC=golang-codereviews
https://golang.org/cl/177780043
The garbage collector is now written in Go.
There is plenty to clean up (just like on dev.cc).
all.bash passes on darwin/amd64, darwin/386, linux/amd64, linux/386.
TBR=rlh
R=austin, rlh, bradfitz
CC=golang-codereviews
https://golang.org/cl/173250043
* _sfloat dispatches to runtime._sfloat2 with the Go calling convention, so the seecond argument is a [15]uint32, not a *[15]uint32.
* adjust _sfloat2 to return the new pc in 68(R13) as expected.
LGTM=rsc
R=minux, austin, rsc
CC=golang-codereviews
https://golang.org/cl/174160043
It's rather unsporting of the kernel to give us a pointer to unaligned memory.
This fixes one crash, the next crash occurs in the soft float emulation.
LGTM=minux, rsc, austin
R=minux, rsc, austin
CC=golang-codereviews
https://golang.org/cl/177730043
warning: src/liblink/asm9.c:501 set and not used: bflag
warning: src/liblink/list9.c:259 format mismatch .5lux INT, arg 4
warning: src/liblink/list9.c:261 format mismatch .5lux INT, arg 3
warning: src/liblink/list9.c:319 more arguments than format VLONG
warning: src/liblink/obj9.c:222 set and not used: autoffset
LGTM=bradfitz, austin
R=rsc, bradfitz
CC=austin, golang-codereviews
https://golang.org/cl/175070043
The pretty printers for these make it hard to understand
what's actually in the fields of these structures. These
"ugly printers" show exactly what's in each field, which can
be useful for understanding and debugging code.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/175780043
This is to reduce the delta between dev.cc and dev.garbage to just garbage collector changes.
These are the files that had merge conflicts and have been edited by hand:
malloc.go
mem_linux.go
mgc.go
os1_linux.go
proc1.go
panic1.go
runtime1.go
LGTM=austin
R=austin
CC=golang-codereviews
https://golang.org/cl/174180043
Now the only difference between dev.cc and dev.garbage
is the runtime conversion on the one side and the
garbage collection on the other. They both have the
same set of changes from default and dev.power64.
LGTM=austin
R=austin
CC=golang-codereviews
https://golang.org/cl/172570043
This is more complicated than the other enums because the D_*
enums are full of explicit initializers and repeated values.
This tries its best. (This will get much cleaner once we
tease these constants apart better.)
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/166700043
Theses were very helpful in understanding the regions and
register selection when porting regopt to 9g. Add them to the
other compilers (and improve 9g's successor debug print).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/174130043
I added several comments to the regopt-related structures when
porting it to 9g. Synchronize those comments back in to the
other compilers.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/175720043
This adds registerization support to 9g equivalent to what the
other compilers have.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/174980043
None of the other compilers have a tag for this enum.
Cleaning all of this up to use proper types will happen after
the conversion.
LGTM=minux, rsc
R=rsc, minux
CC=golang-codereviews
https://golang.org/cl/166690043
Previously, the 6g and 8g registerizers scanned for used
registers beyond the end of a region being considered for
registerization. This ancient artifact was copied from the C
compilers, where it was probably necessary to track implicitly
used registers. In the Go compilers it's harmless (because it
can only over-restrict the set of available registers), but no
longer necessary because the Go compilers correctly track
register use/set information. The consequences of this extra
scan were (at least) that 1) we would not consider allocating
the AX register if there was a deferproc call in the future
because deferproc uses AX as a return register, so we see the
use of AX, but don't track that AX is set by the CALL, and 2)
we could not consider allocating the DX register if there was
a MUL in the future because MUL implicitly sets DX and (thanks
to an abuse of copyu in this code) we would also consider DX
used.
This commit fixes these problems by nuking this code.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/174110043
This was originally done to the C port in rev 17d3b45534b5 and
seemingly got lost during the conversion.
LGTM=bradfitz
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/167700043
Memory management was consolitated with the BSD ports, since
it was almost identical.
Assembly thunks are gone, being replaced by the new //go:linkname
feature.
This change supersedes CL 138390043 (runtime: convert solaris
netpoll to Go), which was previously reviewed and tested.
This change is only the first step, the port now builds,
but doesn't run. Binaries fail to exec:
ld.so.1: 6.out: fatal: 6.out: TLS requirement failure : TLS support is unavailable
Killed
This seems to happen because binaries don't link with libc.so
anymore. We will have to solve that in a different CL.
Also this change is just a rough translation of the original
C code, cleanup will come in a different CL.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=rsc
R=rsc, dave
CC=golang-codereviews, iant, khr, minux, r, rlh
https://golang.org/cl/174960043
Per private thread soliciting help. I realized part of this is
documented in several places, but we lacked a unifying
example.
LGTM=rsc
R=golang-codereviews
CC=adg, golang-codereviews, iant, rsc
https://golang.org/cl/171620043
For D_OREG addresses, store the used registers in regindex
instead of reguse because they're really part of addressing.
Add implicit register use/set for DUFFZERO/DUFFCOPY.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/174050044
Scalararg and ptrarg are not "signal safe".
Go code filling them out can be interrupted by a signal,
and then the signal handler runs, and if it also ends up
in Go code that uses scalararg or ptrarg, now the old
values have been smashed.
For the pieces of code that do need to run in a signal handler,
we introduced onM_signalok, which is really just onM
except that the _signalok is meant to convey that the caller
asserts that scalarg and ptrarg will be restored to their old
values after the call (instead of the usual behavior, zeroing them).
Scalararg and ptrarg are also untyped and therefore error-prone.
Go code can always pass a closure instead of using scalararg
and ptrarg; they were only really necessary for C code.
And there's no more C code.
For all these reasons, delete scalararg and ptrarg, converting
the few remaining references to use closures.
Once those are gone, there is no need for a distinction between
onM and onM_signalok, so replace both with a single function
equivalent to the current onM_signalok (that is, it can be called
on any of the curg, g0, and gsignal stacks).
The name onM and the phrase 'm stack' are misnomers,
because on most system an M has two system stacks:
the main thread stack and the signal handling stack.
Correct the misnomer by naming the replacement function systemstack.
Fix a few references to "M stack" in code.
The main motivation for this change is to eliminate scalararg/ptrarg.
Rick and I have already seen them cause problems because
the calling sequence m.ptrarg[0] = p is a heap pointer assignment,
so it gets a write barrier. The write barrier also uses onM, so it has
all the same problems as if it were being invoked by a signal handler.
We worked around this by saving and restoring the old values
and by calling onM_signalok, but there's no point in keeping this nice
home for bugs around any longer.
This CL also changes funcline to return the file name as a result
instead of filling in a passed-in *string. (The *string signature is
left over from when the code was written in and called from C.)
That's arguably an unrelated change, except that once I had done
the ptrarg/scalararg/onM cleanup I started getting false positives
about the *string argument escaping (not allowed in package runtime).
The compiler is wrong, but the easiest fix is to write the code like
Go code instead of like C code. I am a bit worried that the compiler
is wrong because of some use of uninitialized memory in the escape
analysis. If that's the reason, it will go away when we convert the
compiler to Go. (And if not, we'll debug it the next time.)
LGTM=khr
R=r, khr
CC=austin, golang-codereviews, iant, rlh
https://golang.org/cl/174950043
Also include onM_signalok fix from issue 8995.
Fixes linux/arm build.
Fixes#8995.
LGTM=r
R=r, dave
CC=golang-codereviews
https://golang.org/cl/168580043
This was recorded as an hg mv instead of an hg cp.
For now a C version is needed for the Go compiler.
TBR=r
CC=golang-codereviews
https://golang.org/cl/174020043
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
vlrt.c was only called from C. Pure delete.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r, austin
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/174860043
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/174830044
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r, daniel.morsing
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/172260043
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/172250044
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r, austin
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/172250043
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
In a few cases, defs_$GOOS_$GOARCH.go already existed,
so the target here is defs1_$GOOS_$GOARCH.go.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/171490043
float.c held bit patterns for special float64 values,
hiding from the real uses. Rewrite Go code not to
refer to those values directly.
Convert library routines in runtime.c and string.c.
LGTM=r
R=r, dave
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/170330043
Otherwise no system will get an 'ok' until they all do.
LGTM=r, dave
R=r, dave
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/170320044
The main change is that #include "zasm_GOOS_GOARCH.h"
is now #include "go_asm.h" and/or #include "go_tls.h".
Also, because C StackGuard is now Go _StackGuard,
the assembly name changes from const_StackGuard to
const__StackGuard.
In asm_$GOARCH.s, add new function getg, formerly
implemented in C.
The renamed atomics now have Go wrappers, to get
escape analysis annotations right. Those wrappers
are in CL 174860043.
LGTM=r, aram
R=r, aram
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/168510043
This code overused macros and could not be
converted automatically. Instead a new sigctxt
type had to be defined for each os/arch combination,
with a common (implicit) interface used by the
arch-specific signal handler code.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/168500044
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/168500043
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r, austin
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/167550043
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/167540043
The conversion was done with an automated tool and then
modified only as necessary to make it compile and run.
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
LGTM=r
R=r, dave
CC=austin, dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/166520043
Add missing write barrier when initializing state
for newly created goroutine. Add write barrier for
same slot when preempting a goroutine.
Disable write barrier during goroutine death,
because dopanic does pointer writes.
With concurrent mark enabled (not in this CL), all.bash passed once.
The second time, TestGoexitCrash-2 failed.
LGTM=rlh
R=rlh
CC=golang-codereviews
https://golang.org/cl/167610043
Language clarification.
The existing rules for selector expressions imply
automatic dereferencing of pointers to struct fields.
They also implied automatic dereferencing of selectors
denoting methods. In almost all cases, such automatic
dereferencing does indeed take place for methods but the
reason is not the selector rules but the fact that method
sets include both methods with T and *T receivers; so for
a *T actual receiver, a method expecting a formal T
receiver, also accepts a *T (and the invocation or method
value expression is the reason for the auto-derefering).
However, the rules as stated so far implied that even in
case of a variable p of named pointer type P, a selector
expression p.f would always be shorthand for (*p).f. This
is true for field selectors f, but cannot be true for
method selectors since a named pointer type always has an
empty method set.
Named pointer types may never appear as anonymous field
types (and method receivers, for that matter), so this
only applies to variables declared of a named pointer
type. This is exceedingly rare and perhaps shouldn't be
permitted in the first place (but we cannot change that).
Amended the selector rules to make auto-deref of values
of named pointer types an exception to the general rules
and added corresponding examples with explanations.
Both gc and gccgo have a bug where they do auto-deref
pointers of named types in method selectors where they
should not:
See http://play.golang.org/p/c6VhjcIVdM , line 45.
Fixes#5769.
Fixes#8989.
LGTM=r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/168790043
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
- Remove references to C compiler directories.
- Remove generation of special header files.
- Remove generation of Go source files from C declarations.
- Compile Go sources before rest of package (was after),
so that Go compiler can write go_asm.h for use in assembly.
- Move TLS information from cmd/dist (was embedding in output)
to src/runtime/go_tls.h, which it can be maintained directly.
LGTM=r
R=r, dave
CC=austin, golang-codereviews, iant, khr
https://golang.org/cl/172960043
If the linker finds the same name given a BSS and a non-BSS
symbol, the assumption is that the non-BSS symbol is the
true one, and the BSS symbol is just the best Go can do toward
an "extern" declaration. This has always been the case,
as long as the object files were read in the right order.
The old code worked when the BSS symbol is found before
the non-BSS symbol. This CL adds equivalent logic for when
the non-BSS symbol is found before the BSS symbol.
This comes up when Go must refer to symbols defined in
host object files.
LGTM=r
R=r
CC=austin, golang-codereviews, iant, khr
https://golang.org/cl/171480043
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
Make gcToolchain.cc return an error (no C compiler!).
Adjust expectations of cgo, now that cgo does not write any C files
(no C compiler!).
For packages with .s files, invoke Go compiler with -asmhdr go_asm.h
so that assembly files can use it. This applies to all packages but is only
needed today by package runtime.
LGTM=r
R=r
CC=austin, golang-codereviews, iant, khr
https://golang.org/cl/171470043
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
export.c, lex.c:
Add -asmhdr flag to write assembly header file with struct
field offsets and const values. cmd/dist used to construct this
file by interpreting output from the C compiler.
Generate it from the Go definitions instead.
Also, generate the form we need directly, instead of relying
on cmd/dist for reprocessing.
lex.c, obj.c:
If the C compiler accepted #pragma cgo_xxx, recognize
a directive //go:cgo_xxx instead. The effect is the same as
in the C compiler: accumulate text into a buffer and emit in the
output file, where the linker will find and use it.
lex.c, obj.c:
Accept //go:linkname to control the external symbol name
used for a particular top-level Go variable. This makes it
possible to refer to C symbol names but also symbols from
other packages. It has always been possible to do this from
C and assembly. To drive home the point that this should not
be done lightly, require import "unsafe" in any file containing
//go:linkname.
plive.c, reflect.c, subr.c:
Hard-code that interfaces contain only pointers.
This means code handling multiword values in the garbage
collector and the stack copier can be deleted instead of being
converted. This change is already present in the dev.garbage
branch.
LGTM=r
R=r
CC=austin, golang-codereviews, iant, khr
https://golang.org/cl/169360043
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
We changed cgo to write the actual function wrappers in Go
for Go 1.4. The only code left in C output files was the definitions
for pointers to C data and the #pragma cgo directives.
Write both of those to Go outputs instead, using the new
compiler directives introduced in CL 169360043.
(Still generating C files in gccgo mode.)
LGTM=r
R=r
CC=austin, golang-codereviews, iant, khr
https://golang.org/cl/169330045
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
Adjustments for changes made in CL 169360043.
This change is already present in the dev.garbage branch.
LGTM=r
R=r
CC=austin, golang-codereviews, iant, khr
https://golang.org/cl/167520044
Let's just do this up front.
This will break the build (here on the dev.cc branch).
The CLs that follow will take care of fixing it.
Leave behind cmd/cc/lexbody and cmd/cc/macbody for the assemblers.
They'll go away later.
LGTM=dave, r
R=r, dave
CC=golang-codereviews
https://golang.org/cl/172170043
To turn concurrent gc on alter the if false in func gogc
currently at line 489 in malloc.go
LGTM=rsc
R=rsc
CC=golang-codereviews, rlh
https://golang.org/cl/172190043
This patch is based only on reading the code. I have not
tried to construct a test case.
Fixes#9077.
LGTM=minux
R=minux
CC=golang-codereviews
https://golang.org/cl/172110043
This branch is for work on converting the remaining C code in
package runtime to Go and then deleting the cc, 5c, 6c, and 8c
directories. It is targeted to land at the beginning of the 1.5 cycle.
The conversion will proceed one GOOS/GOARCH combination
at a time; red lines on the dashboard are expected and okay.
Once Linux and OS X are converted, help with other systems
will be most welcome.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/174760043
Manifested as increased memory usage in a Google production system.
Not an unbounded leak, but can significantly increase the number
of sudogs allocated between garbage collections.
I checked all the other calls to acquireSudog.
This is the only one that was missing a releaseSudog.
LGTM=r, dneil
R=dneil, r
CC=golang-codereviews
https://golang.org/cl/169260043
These are being built into the runtime/cgo for every
operating system. It doesn't seem to matter, but
restore the Go 1.3 behavior anyway.
LGTM=r
R=r, dave
CC=golang-codereviews
https://golang.org/cl/171290043
This was a mistake. The cmd/api tool
depends on an old version of go/types.
««« original CL description
cmd/api: use golang.org/x/... import paths
LGTM=bradfitz, rsc
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/169000043
»»»
TBR=rsc, bradfitz
R=bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/169320043
This was a mistake; the cmd/api tool
depends on an old version of go/types.
««« original CL description
cmd/api: bump go.tools golden CL hash
TBR=bradfitz
R=rsc
CC=golang-codereviews
https://golang.org/cl/166380043
»»»
TBR=bradfitz, rsc
R=bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/167430043
I've Mercurial version 3.2 and hg submit fails with:
File "/home/agl/devel/go/lib/codereview/codereview.py", line 3567, in get_hg_status
ret = hg_commands.status(fui, self.repo, *[], **{'rev': [rev], 'copies': True})
File "/usr/lib/python2.7/site-packages/mercurial/commands.py", line 5714, in status
fm = ui.formatter('status', opts)
File "/home/agl/devel/go/lib/codereview/codereview.py", line 3464, in formatter
return plainformatter(self, topic, opts)
File "/usr/lib/python2.7/site-packages/mercurial/formatter.py", line 57, in __init__
if ui.debugflag:
AttributeError: 'FakeMercurialUI' object has no attribute 'debugflag'
This change dumbly adds a boolean debugflag and that seems to work.
LGTM=minux
R=rsc, minux
CC=golang-codereviews
https://golang.org/cl/167410043
New detection because of net/http now using TestMain.
Fixes#9033
LGTM=iant
R=golang-codereviews, iant
CC=adg, golang-codereviews, rsc
https://golang.org/cl/170210043
Replace a bit-wise AND with a logical one. This happened to
work before because bany returns 0 or 1, but the intent here
is clearly logical (and this makes 5g match with 6g and 8g).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/172850043
This was missing from CL 167320043.
Happy to apply comments in a followup.
TBR to fix build.
TBR=r
CC=golang-codereviews
https://golang.org/cl/171260043
Moving so that new Go 1.4 pprof can use it.
The old 'GNU objdump workalike' mode for 'go tool objdump'
is now gone, as are the tests for that mode. It was used only
by pre-Go 1.4 pprof. You can still specify an address range on
the command line; you just get the same output format as
you do when dumping the entire binary (without an address
limitation).
LGTM=r
R=r
CC=golang-codereviews, iant
https://golang.org/cl/167320043
For OITAB nodes, 5g's naddr was setting the wrong etype and
failing to set the width of the resulting Addr.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/171220043
People viewing this locally will not have a /s/ on their local godoc.
tip.golang.org doesn't have one either.
Also change all golang.org links to https, to avoid mixed content
warnings when viewing https://golang.org/.
Fixes#9028.
LGTM=bradfitz, r
R=r, bradfitz
CC=adg, golang-codereviews
https://golang.org/cl/168250043
The remaining run-only tests will be migrated to run.go in another CL.
This CL will break the build due to issues 8746 and 8806.
Update #4139
Update #8746
Update #8806
LGTM=rsc
R=rsc, bradfitz, iant
CC=golang-codereviews
https://golang.org/cl/144630044
9g's naddr was missing assignments to a->width in several
cases, so the optimizer was getting bogus width information.
Add them.
This correct width information also lets us enable the width
check in gins for MOV*.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/167310043
The etype of references to strings was being incorrectly set
to TINT32 on all platforms. Change it to TSTRING. It seems
this doesn't matter for compilation, since x86 uses LEA
instructions to load string addresses and arm and power64
disassemble the string into its constituent pieces (with the
correct types), but it helps when debugging.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/170100043
Stack bitmaps need to be scanned past any BitsDead entries.
Object bitmaps will not have any BitsDead in them (bitmap extraction stops at
the first BitsDead entry in makeheapobjbv). data/bss bitmaps also have no BitsDead entries.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/168270043
For some reason lsof is now hanging on my workstation
without the -b (avoid blocking in the kernel) option.
Adding -b makes the test pass and shouldn't hurt.
I don't know how recent the -b option is. If the builders
are ok with it, it's probably ok.
LGTM=rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/166220043
Gentraceback may grow the stack.
One of the gentraceback wrappers may grow the stack.
One of the gentraceback callback calls may grow the stack.
Various stack pointers are stored in various stack locations
as type uintptr during the execution of these calls.
If the stack does grow, these stack pointers will not be
updated and will start trying to decode stack memory that
is no longer valid.
It may be possible to change the type of the stack pointer
variables to be unsafe.Pointer, but that's pretty subtle and
may still have problems, even if we catch every last one.
An easier, more obviously correct fix is to require that
gentraceback of the currently running goroutine must run
on the g0 stack, not on the goroutine's own stack.
Not doing this causes faults when you set
StackFromSystem = 1
StackFaultOnFree = 1
The new check in gentraceback will catch future lapses.
The more general problem is calling getcallersp but then
calling a function that might relocate the stack, which would
invalidate the result of getcallersp. Add note to stubs.go
declaration of getcallersp explaining the problem, and
check all existing calls to getcallersp. Most needed fixes.
This affects Callers, Stack, and nearly all the runtime
profiling routines. It does not affect stack copying directly
nor garbage collection.
LGTM=khr
R=khr, bradfitz
CC=golang-codereviews, r
https://golang.org/cl/167060043
The new rules for split functions mean that we are exposed
to the common bug of a function that loops forever at EOF.
Pick these off by shutting down the scanner if too many
consecutive empty tokens are delivered.
Fixes#9020.
LGTM=rsc, adg
R=golang-codereviews, rsc, adg, bradfitz
CC=golang-codereviews
https://golang.org/cl/169970043
Previously, mkvar treated, for example, 0(AX) the same as AX.
As a result, a move to an indirect address would be marked as
*setting* the register, rather than just using it, resulting
in unnecessary register moves. Fix this by not producing
variables for indirect addresses.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/164610043
The test intended to skip direct calls when creating
registerization variables was testing p->to.type instead of
p->to.name, so it always failed, causing regopt to create
unnecessary variables for these names.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/169110043
Now each C printf, Go print, or Go println is guaranteed
not to be interleaved with other calls of those functions.
This should help when debugging concurrent failures.
LGTM=rlh
R=rlh
CC=golang-codereviews
https://golang.org/cl/169120043
- Some sequencing issues with stopping the first gc_m round
at the right place to set up correctly for the second round.
- atomicxor8 is not idempotent; avoid xor.
- Maintain BitsDead type bits correctly; see long comment added.
- Enable checkmark phase by default for now.
LGTM=rlh
R=rlh
CC=golang-codereviews
https://golang.org/cl/171090043
So far all of our architectures have had at most 32 registers,
so we've been able to use entry 0 in the Bits uint32 array
directly as a register mask. Power64 has 64 registers, so
this converts Bits to a uint64 array so we can continue to use
entry 0 directly as a register mask on Power64.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/169060043
This adds an independent mark phase to the GC that can be used to
verify the the default concurrent mark phase has found all reachable
objects. It uses the upper 2 bits of the boundary nibble to encode
the mark leaving the lower bits to encode the boundary and the
normal mark bit.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/167130043
One failing case this removes is:
var bytes = []byte("hello, world")
var copy_bytes = bytes
We could handle this in the compiler, but it requires special
case for a variable that is initialized to the value of a
variable that is initialized to a string literal converted to
[]byte. This seems an unlikely case--it never occurs in the
standrd library--and it seems unnecessary to write the code to
handle it.
If we do want to support this case, one approach is
https://golang.org/cl/171840043.
The other failing cases are of the form
var bx bool
var copy_bx = bx
The compiler used to initialize copy_bx to false. However,
that led to issue 7665, since bx may be initialized in non-Go
code. The compiler no longer assumes that bx must be false,
so copy_bx can not be statically initialized.
We can fix these with https://golang.org/cl/169040043
if we also pass -complete to the compiler as part of this
test. This is OK but it's too late in the release cycle.
Fixes#8746.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/165400043
The check for unknown command line debug flags in gc was
incorrect: the loop over debugtab terminates when it reaches a
nil entry, but it was only reporting an error if the parser
had passed the last entry of debugtab (which it never did).
Fix this by reporting the usage error if the loop reaches a
nil entry.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/166110043
On power64x, this one line in live.go reports that t is live
because of missing optimization passes. This isn't what this
test is trying to test, so shuffle bad40 so that it still
accomplishes the intent of the test without also depending on
optimization.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/167110043
The remaining failures in this test are because of incomplete
optimization support on power64x. Tracked in issue 9058.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/168130043
Print PC stored in target Prog* of branch instructions when
available instead of the offset stored in the branch
instruction. The offset tends to be wrong after code
transformations, so previously this led to confusing listings.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/168980043
Previously, nilopt was disabled on power64x because it threw
away "seemly random segments of code." Indeed, excise on
power64x failed to preserve the link field, so it excised not
only the requested instruction but all following instructions
in the function. Fix excise to retain the link field while
otherwise zeroing the instruction.
This makes nilopt safe on power64x. It still fails
nilptr3.go's tests for removal of repeated nil checks because
those depend on also optimizing away repeated loads, which
doesn't currently happen on power64x.
LGTM=dave, rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/168120043
(The assertion depends on a per-package gensym counter whose
value varies based on what else is in the package.)
LGTM=khr
R=khr, rsc
CC=golang-codereviews
https://golang.org/cl/169930043
Previously, the flags argument to mallocgc was an int in Go,
but a uint32 in C. Change the Go type to use uint32 so these
agree. The largest flag value is 2 (and of course no flag
values are negative), so this won't change anything on little
endian architectures, but it matters on big endian.
LGTM=rsc
R=khr, rsc
CC=golang-codereviews
https://golang.org/cl/169920043
On heavily loaded build servers, a 5 second timeout is too aggressive,
which causes this test to fail spuriously.
LGTM=iant
R=iant
CC=golang-codereviews, sqweek
https://golang.org/cl/170850043
The GC info masks for slices and strings were changed in
commit caab29a25f68, but the reference masks used by
gcinfo_test for power64x hadn't caught up. Now they're
identical to amd64, so this CL fixes this test by combining
the reference masks for these platforms.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/162620044
reflect/asm_power64x.s was missing changes made to other
platforms for stack maps. This CL ports those changes. With
this fix, the reflect test passes on power64x.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/170870043
fastrand1 depends on testing the high bit of its uint32 state.
For efficiency, all of the architectures implement this as a
sign bit test. However, on power64, fastrand1 was using a
64-bit sign test on the zero-extended 32-bit state. This
always failed, causing fastrand1 to have very short periods
and often decay to 0 and get stuck.
Fix this by using a 32-bit signed compare instead of a 64-bit
compare. This fixes various tests for the randomization of
select of map iteration.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/166990043
All three cases of clearfat were wrong on power64x.
The cases that handle 1032 bytes and up and 32 bytes and up
both use MOVDU (one directly generated in a loop and the other
via duffzero), which leaves the pointer register pointing at
the *last written* address. The generated code was not
accounting for this, so the byte fill loop was re-zeroing the
last zeroed dword, rather than the bytes following the last
zeroed dword. Fix this by simply adding an additional 8 byte
offset to the byte zeroing loop.
The case that handled under 32 bytes was also wrong. It
didn't update the pointer register at all, so the byte zeroing
loop was simply re-zeroing the beginning of region. Again,
the fix is to add an offset to the byte zeroing loop to
account for this.
LGTM=dave, bradfitz
R=rsc, dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/168870043
Apparently I had already moved on to fixing another problem
when I submitted CL 169790043.
LGTM=dave
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/165210043
No real problems found. Just lots of argument names that
didn't quite match up.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/169790043
This adds a test to runtime·check to ensure CAS of large
unsigned 32-bit numbers does not accidentally sign-extend its
arguments.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/162490044
Previously, the power64x runtime assembly was sloppy about
using sign-extending versus zero-extending moves of arguments
and return values. I think all of the cases that actually
mattered have been fixed in recent CLs; this CL fixes up the
few remaining mismatches.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/162480043
This CL implements the many multiword write barriers by calling
writebarrierptr, so that only writebarrierptr needs the actual barrier.
In lieu of an actual barrier, writebarrierptr checks that the value
being copied is not a small non-zero integer. This is enough to
shake out bugs where the barrier is being called when it should not
(for non-pointer values). It also found a few tests in sync/atomic
that were being too clever.
This CL adds a write barrier for the memory moved during the
builtin copy function, which I forgot when inserting barriers for Go 1.4.
This CL re-enables some write barriers that were disabled for Go 1.4.
Those were disabled because it is possible to change the generated
code so that they are unnecessary most of the time, but we have not
changed the generated code yet. For safety they must be enabled.
None of this is terribly efficient. We are aiming for correct first.
LGTM=rlh
R=rlh
CC=golang-codereviews
https://golang.org/cl/168770043
If you get a stack of PCs from Callers, it would be expected
that every PC is immediately after a call instruction, so to find
the line of the call, you look up the line for PC-1.
CL 163550043 now explicitly documents that.
The most common exception to this is the top-most return PC
on the stack, which is the entry address of the runtime.goexit
function. Subtracting 1 from that PC will end up in a different
function entirely.
To remove this special case, make the top-most return PC
goexit+PCQuantum and then implement goexit in assembly
so that the first instruction can be skipped.
Fixes#7690.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/170720043
This removes a bunch of ugly duplicate code.
The end goal is to factor the disassembly code
into cmd/internal/objfile too, so that pprof can use it,
but one step at a time.
LGTM=r, iant
R=r, alex.brainman, iant
CC=golang-codereviews
https://golang.org/cl/149400043
Originally traceback was only used for printing the stack
when an unexpected signal came in. In that case, the
initial PC is taken from the signal and should be used
unaltered. For the callers, the PC is the return address,
which might be on the line after the call; we subtract 1
to get to the CALL instruction.
Traceback is now used for a variety of things, and for
almost all of those the initial PC is a return address,
whether from getcallerpc, or gp->sched.pc, or gp->syscallpc.
In those cases, we need to subtract 1 from this initial PC,
but the traceback code had a hard rule "never subtract 1
from the initial PC", left over from the signal handling days.
Change gentraceback to take a flag that specifies whether
we are tracing a trap.
Change traceback to default to "starting with a return PC",
which is the overwhelmingly common case.
Add tracebacktrap, like traceback but starting with a trap PC.
Use tracebacktrap in signal handlers.
Fixes#7690.
LGTM=iant, r
R=r, iant
CC=golang-codereviews
https://golang.org/cl/167810044
Attempt to clear up confusion about how to turn
the PCs reported by Callers into the file and line
number people actually want.
Fixes#7690.
LGTM=r, chris.cs.guy
R=r, chris.cs.guy
CC=golang-codereviews
https://golang.org/cl/163550043
The goal here is to get the big-endian fixes so that
in some upcoming code movement for write barriers
I don't make them unmergeable.
LGTM=rlh
R=rlh
CC=golang-codereviews
https://golang.org/cl/166890043
goprintf is a printf-like print for Go.
It is used in the code generated by 'defer print(...)' and 'go print(...)'.
Normally print(1, 2, 3) turns into
printint(1)
printint(2)
printint(3)
but defer and go need a single function call to give the runtime;
they give the runtime something like goprintf("%d%d%d", 1, 2, 3).
Variadic functions like goprintf cannot be described in the new
type information world, so we have to replace it.
Replace with a custom function, so that defer print(1, 2, 3) turns
into
defer func(a1, a2, a3 int) {
print(a1, a2, a3)
}(1, 2, 3)
(and then the print becomes three different printints as usual).
Fixes#8614.
LGTM=austin
R=austin
CC=golang-codereviews, r
https://golang.org/cl/159700043
I removed support for jumping between functions years ago,
as part of doing the instruction layout for each function separately.
Given that, it makes sense to treat labels as function-scoped.
This lets each function have its own 'loop' label, for example.
Makes the assembly much cleaner and removes the last
reason anyone would reach for the 123(PC) form instead.
Note that this is on the dev.power64 branch, but it changes all
the assemblers. The change will ship in Go 1.5 (perhaps after
being ported into the new assembler).
Came up as part of CL 167730043.
LGTM=r
R=r
CC=austin, dave, golang-codereviews, minux
https://golang.org/cl/159670043
In CL 160670043 the write function was changed
so a zero-length write is now allowed. This leads
the ExampleWriter_Init test to fail.
The reason is that Plan 9 preserves message
boundaries, while the os library expects systems
that don't preserve them. We have to ignore
zero-length writes so they will never turn into EOF.
This issue was previously discussed in CL 7406046.
LGTM=bradfitz
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/163510043
Power64 servers do not currently support sub-word size atomic
memory access, so atomicor8 uses word size atomic access.
However, previously atomicor8 made no attempt to align this
access, resulting in errors. Fix this by aligning the pointer
to a word boundary and shifting the value appropriately.
Since atomicor8 is used in GC, add a test to runtime·check to
make sure this doesn't break in the future.
This also fixes an incorrect branch label, an incorrectly
sized argument move, and adds argument names to help go vet.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/165820043
The "to" field was the penultimate argument to outgcode,
instead of the last argument, which swapped the third and
fourth operands. The argument order was correct in a.y, so
just swap the meaning of the arguments in outgcode. This
hadn't come up because we hadn't used these more obscure
operations in any hand-written assembly until now.
LGTM=rsc, dave
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/160690043
No easy way to test (would have to actually trigger some routing
events from kernel) but the code is clearly wrong as written.
If the header says there is a submessage, we need to at least
skip over its bytes, not just continue to the next iteration.
Fixes#8203.
LGTM=r
R=r
CC=golang-codereviews, mikioh.mikioh, p
https://golang.org/cl/164140044
get -u now checks that remote repo paths match the
ones predicted by the import paths: if you are get -u'ing
rsc.io/pdf, it has to be checked out from the right location.
This is important in case the rsc.io/pdf redirect changes.
In some cases, people have good reasons to use
non-standard remote repos. Add -f flag to allow that.
The f can stand for force or fork, as you see fit.
Fixes#8850.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/164120043
The wrapper code was being emitted before the stack
reservation, rather than after.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/161540043
Just to confirm the fix, by typing the follwing:
go test -run=TestLookupIPDeadline -dnsflood or
go test -run=TestLookupIPDeadline -dnsflood -tags netgo
Update #8602
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/166740043
Add a short introductory section saying what most Go
programmers really need to know, which is that you
shouldn't have to read this document to understand
the behavior of your program.
LGTM=bradfitz, adg, tracey.brendan, iant, rsc, dsymonds
R=golang-codereviews, bradfitz, tracey.brendan, adg, iant, rsc, dsymonds
CC=golang-codereviews
https://golang.org/cl/158500043
Not a language change.
This is simply documenting the status quo which permits
builtin function names to be parenthesized in calls; e.g.,
both
len(s)
and
(((len)))(s)
are accepted by all compilers and go/types.
Changed the grammar by merging the details of BuiltinCall
with ordinary Calls. Also renamed the Call production to
Arguments which more clearly identifies that part of the
grammar and also matches better with its counterpart on
the declaration side (Parameters).
The fact that the first argument can be a type (for builtins)
or cannot be a type (for regular function calls) is expressed
in the prose, no need to make the grammar more complicated.
Fixes#9001.
LGTM=iant, r, rsc
R=r, rsc, iant, ken, dave
CC=golang-codereviews
https://golang.org/cl/160570043
The test just doubled a certain number of times
and then gave up. On a mostly fast but occasionally
slow machine this may never make the test run
long enough to see the linear growth.
Change test to keep doubling until the first round
takes at least a full second, to reduce the effect of
occasional scheduling or other jitter.
The failure we saw had a time for the first round
of around 100ms.
Note that this test still passes once it sees a linear
effect, even with a very small total time.
The timeout here only applies to how long the execution
must be to support a reported failure.
LGTM=khr
R=khr
CC=golang-codereviews, rlh
https://golang.org/cl/164070043
Fix include paths that got moved in the great pkg/ rename. Add
missing runtime/arch_* files for power64. Port changes that
happened on default since branching to
runtime/{asm,atomic,sys_linux}_power64x.s (precise stacks,
calling convention change, various new and deleted functions.
Port struct renaming and fix some bugs in
runtime/defs_linux_power64.h.
LGTM=rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/161450043
Move the release notes into an HTML file.
Start writing the text.
LGTM=rsc
R=golang-codereviews, bradfitz, kamil.kisiel, tracey.brendan, rsc
CC=golang-codereviews
https://golang.org/cl/161350043
A recent commit lost the branch target in the really-big-stack
case of splitstack, causing an infinite loop stack preempt
case. Revive the branch target.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/157790044
The ftab ends with a half functab record consisting only of
the 'entry' field followed by a uint32 giving the offset of
the next table. Previously, symtabinit assumed it could read
this uint32 as a uintptr. Since this is unsafe on big endian,
explicitly read the offset as a uint32.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/157660043
Ports of platform-specific changes that happened on default
after dev.power64 forked (fixes for c2go, wrapper math fixes,
moved stackguard field, stackguard1 support, precise stacks).
Bug fixes (missing AMOVW in instruction table, correct
unsigned 32-bit remainder).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/164920044
This test gives a false negative at an observed rate of 1 in a 1000
due to the fact that it runs for < 100 ms. allowing GC pauses to
warp the results. Changed the test so that it triggers only if it
remains non-linear for much larger problem sizes.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/164010043
Before this CL, if the system resolver does a very slow DNS
lookup for a particular host, all subsequent requests for that
host will hang waiting for that lookup to complete. That is
more or less expected when Dial is called with no deadline.
When Dial has a deadline, though, we can accumulate a large
number of goroutines waiting for that slow DNS lookup. Try to
avoid this problem by restarting the DNS lookup when it is
redone after a deadline is passed.
This CL also avoids creating an extra goroutine purely to
handle the deadline.
No test because we would have to simulate a slow DNS lookup
followed by a fast DNS lookup.
Fixes#8602.
LGTM=bradfitz
R=bradfitz, mikioh.mikioh
CC=golang-codereviews, r, rsc
https://golang.org/cl/154610044
ARPHELPLINK yields 404; update the URL.
While here, also prefix the ARPREADME and ARPURLINFOABOUT URL's with the HTTP scheme to make 'em clickable links in the Add or Remove Programs listing.
LGTM=adg
R=golang-codereviews
CC=adg, golang-codereviews
https://golang.org/cl/154580045
Wrong article, one stylistic point that bothers someone (but not me).
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/156680043
The compatibility guideline needs to be clear about this even
though it means adding a clause that was not there from the
beginning. It has always been understood, so this isn't really
a change in policy, just in its expression.
LGTM=bradfitz, gri, rsc
R=golang-codereviews, bradfitz, gri, rsc
CC=golang-codereviews
https://golang.org/cl/162060043
Routines and logic to preform a concurrent stack scan of go-routines.
This CL excersizes most of the functionality needed. The
major exception being that it does not scan running goroutines.
After doing the scans it relies on a STW to finish the GC, including
rescanning the stacks. It is intended to achieve correctness,
performance will follow.
LGTM=rsc
R=golang-codereviews, rsc
CC=dvyukov, golang-codereviews
https://golang.org/cl/156580043
We force runtime.GC before WriteHeapProfile with -test.heapprofile.
Make it possible to do the same with the HTTP interface.
Some servers only run a GC every few minutes.
On such servers, the heap profile will be a few minutes stale,
which may be too old to be useful.
Requested by private mail.
LGTM=dvyukov
R=dvyukov
CC=golang-codereviews
https://golang.org/cl/161990043
In theory both of these lines encode the same three fields:
a,,c
a,"",c
However, Postgres defines that when importing CSV, the unquoted
version is treated as NULL (missing), while the quoted version is
treated as a string value (empty string). If the middle field is supposed to
be an integer value, the first line can be imported (NULL is okay), but
the second line cannot (empty string is not).
Postgres's import command (COPY FROM) has an option to force
the unquoted empty to be interpreted as a string but it does not
have an option to force the quoted empty to be interpreted as a NULL.
From http://www.postgresql.org/docs/9.0/static/sql-copy.html:
The CSV format has no standard way to distinguish a NULL
value from an empty string. PostgreSQL's COPY handles this
by quoting. A NULL is output as the NULL parameter string
and is not quoted, while a non-NULL value matching the NULL
parameter string is quoted. For example, with the default
settings, a NULL is written as an unquoted empty string,
while an empty string data value is written with double
quotes (""). Reading values follows similar rules. You can
use FORCE_NOT_NULL to prevent NULL input comparisons for
specific columns.
Therefore printing the unquoted empty is more flexible for
imports into Postgres than printing the quoted empty.
In addition to making the output more useful with Postgres, not
quoting empty strings makes the output smaller and easier to read.
It also matches the behavior of Microsoft Excel and Google Drive.
Since we are here and making concessions for Postgres, handle this
case too (again quoting the Postgres docs):
Because backslash is not a special character in the CSV
format, \., the end-of-data marker, could also appear as a
data value. To avoid any misinterpretation, a \. data value
appearing as a lone entry on a line is automatically quoted
on output, and on input, if quoted, is not interpreted as
the end-of-data marker. If you are loading a file created by
another application that has a single unquoted column and
might have a value of \., you might need to quote that value
in the input file.
Fixes#7586.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/164760043
The changes got rid of the problems we were seeing.
We suspect the pushcnt field has a race.
LGTM=rsc
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/159330043
Per suggestion from rsc as a result of the dicussion of
(abandoned) CL 153110044.
Fixes#7192.
LGTM=r, rsc, iant
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/163050043
Also updated defs3_linux.go but had to manually edit defs_linux_power64le.h. Will regenerate the file when cgo is working natively on ppc64.
LGTM=austin
R=rsc, austin
CC=golang-codereviews
https://golang.org/cl/158360043
go_bootstrap was panicking during runtime initialization
(under runtime.main) because Defer objects were being
prematurely GC'd. This happened because of an incorrect
change to runtime·unrollgcprog_m to make it endian-agnostic
during the conversion of runtime bitmaps to byte arrays.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/161960044
This brings dev.power64 up-to-date with the current tip of
default. go_bootstrap is still panicking with a bad defer
when initializing the runtime (even on amd64).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/152570049
The earlier dev.power64 merge missed the port of
runtime/noasm.goc to runtime/noasm_arm.go. This CL fixes this
by moving noasm_arm.go to noasm.go and adding a +build to
share the file between arm and power64.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/158350043
This also removes pkg/runtime/traceback_lr.c, which was ported
to Go in an earlier commit and then moved to
runtime/traceback.go.
Reviewer: rsc@golang.org
rsc: LGTM
Pool memory was only being released during the first GC after the first Put.
Put assumes that p.local != nil means p is on the allPools list.
poolCleanup (called during each GC) removed each pool from allPools
but did not clear p.local, so each pool was cleared by exactly one GC
and then never cleared again.
This bug was introduced late in the Go 1.3 release cycle.
Fixes#8979.
LGTM=rsc
R=golang-codereviews, bradfitz, r, rsc
CC=golang-codereviews, khr
https://golang.org/cl/162980043
test16 used to fail with gccgo. The withoutRecoverRecursive
test would have failed in some possible implementations.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/151630043
Fixes#8348.
Trying to work around clang's dodgy support for .arch by reverting to the external assembler didn't work out so well. Minux had a much better solution to encode the instructions we need as .word directives which avoids .arch altogether.
I've confirmed with gdb that this form produces the expected machine code
Dump of assembler code for function crosscall_arm1:
0x00000000 <+0>: push {r4, r5, r6, r7, r8, r9, r10, r11, r12, lr}
0x00000004 <+4>: mov r4, r0
0x00000008 <+8>: mov r5, r1
0x0000000c <+12>: mov r0, r2
0x00000010 <+16>: blx r5
0x00000014 <+20>: blx r4
0x00000018 <+24>: pop {r4, r5, r6, r7, r8, r9, r10, r11, r12, pc}
There is another compilation failure that blocks building Go with clang on arm
# ../misc/cgo/test
# _/home/dfc/go/misc/cgo/test
/tmp/--407b12.s: Assembler messages:
/tmp/--407b12.s:59: Error: selected processor does not support ARM mode `blx r0'
clang: error: assembler command failed with exit code 1 (use -v to see invocation)
FAIL _/home/dfc/go/misc/cgo/test [build failed]
I'll open a new issue for that
LGTM=iant
R=iant, minux
CC=golang-codereviews
https://golang.org/cl/158180047
Set correct version number at Windows installer based on
Go's Mercurial tag.
Name | Version
------------------------------------------------
Go Programming Language amd64 go1.3.3 | 1.3.3
Go Programming Language amd64 go1.2rc3 | 1.2
Go Programming Language amd64 go1.2beta1 | 1.2
Fixes#8239.
LGTM=adg
R=adg, c.emil.hessman, alex.brainman
CC=golang-codereviews
https://golang.org/cl/160950044
Partial undo, changes to ldelf.c retained.
Some platforms are still not working even with the integrated assembler disabled, will have to find another solution.
««« original CL description
cmd/cgo: disable clang's integrated assembler
Fixes#8348.
Clang's internal assembler (introduced by default in clang 3.4) understands the .arch directive, but doesn't change the default value of -march. This causes the build to fail when we use BLX (armv5 and above) when clang is compiled for the default armv4t architecture (which appears to be the default on all the distros I've used).
This is probably a clang bug, so work around it for the time being by disabling the integrated assembler when compiling the cgo assembly shim.
This CL also includes a small change to ldelf.c which was required as clang 3.4 and above generate more weird symtab entries.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/156430044
»»»
LGTM=minux
R=iant, minux
CC=golang-codereviews
https://golang.org/cl/162880044
Get rid of gocputicks(), it is no longer used.
LGTM=bradfitz, dave
R=golang-codereviews, bradfitz, dave, minux
CC=golang-codereviews
https://golang.org/cl/161110044
This brings cmd/gc in line with the spec on this question.
It might break existing code, but that code was not conformant
with the spec.
Credit to Rémy for finding the broken code.
Fixes#6366.
LGTM=r
R=golang-codereviews, r
CC=adonovan, golang-codereviews, gri
https://golang.org/cl/129550043
Allows parsing some file formats that assign special
meaning to which stream data is found in.
Will do the same for compress/bzip2 once this is
reviewed and submitted.
Fixes#6486.
LGTM=nigeltao
R=nigeltao, dan.kortschak
CC=adg, bradfitz, golang-codereviews, r
https://golang.org/cl/159120044
Fixes#8348.
Clang's internal assembler (introduced by default in clang 3.4) understands the .arch directive, but doesn't change the default value of -march. This causes the build to fail when we use BLX (armv5 and above) when clang is compiled for the default armv4t architecture (which appears to be the default on all the distros I've used).
This is probably a clang bug, so work around it for the time being by disabling the integrated assembler when compiling the cgo assembly shim.
This CL also includes a small change to ldelf.c which was required as clang 3.4 and above generate more weird symtab entries.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/156430044
It has been failing periodically on Solaris/x64.
Change blockevent so it always records an event if we called
SetBlockProfileRate(1), even if the time delta is negative or zero.
Hopefully this will fix the test on Solaris.
Caveat: I don't actually know what the Solaris problem is, this
is just an educated guess.
LGTM=dave
R=dvyukov, dave
CC=golang-codereviews
https://golang.org/cl/159150043
Russ Cox pointed out that environment strings are not
required to be nil-terminated on Plan 9.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/159130044
Since CL 104570043 and 112720043, we are using the
nsec system call instead of /dev/bintime on Plan 9.
LGTM=rsc
R=rsc
CC=aram, golang-codereviews
https://golang.org/cl/155590043
Shell scripts depend on the old behavior too often.
It's too late to make this change.
LGTM=bradfitz
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/161890044
This test was failing but did not break the build because it
was not run when -test.short was used.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/157150043
I came across this while debugging a GC problem in gccgo.
There is code in assignTo and cvtT2I that handles assignment
to all interface values. It allocates an empty interface even
if the real type is a non-empty interface. The fields are
then set for a non-empty interface, but the memory is recorded
as holding an empty interface. This means that the GC has
incorrect information.
This is extremely unlikely to fail, because the code in the GC
that handles empty interfaces looks like this:
obj = nil;
typ = eface->type;
if(typ != nil) {
if(!(typ->kind&KindDirectIface) || !(typ->kind&KindNoPointers))
obj = eface->data;
In the current runtime the condition is always true--if
KindDirectIface is set, then KindNoPointers is clear--and we
always want to set obj = eface->data. So the question is what
happens when we incorrectly store a non-empty interface value
in memory marked as an empty interface. In that case
eface->type will not be a *rtype as we expect, but will
instead be a pointer to an Itab. We are going to use this
pointer to look at a *rtype kind field. The *rtype struct
starts out like this:
type rtype struct {
size uintptr
hash uint32 // hash of type; avoids computation in hash tables
_ uint8 // unused/padding
align uint8 // alignment of variable with this type
fieldAlign uint8 // alignment of struct field with this type
kind uint8 // enumeration for C
An Itab always has at least two pointers, so on a
little-endian 64-bit system the kind field will be the high
byte of the second pointer. This will normally be zero, so
the test of typ->kind will succeed, which is what we want.
On a 32-bit system it might be possible to construct a failing
case by somehow getting the Itab for an interface with one
method to be immediately followed by a word that is all ones.
The effect would be that the test would sometimes fail and the
GC would not mark obj, leading to an invalid dangling
pointer. I have not tried to construct this test.
I noticed this in gccgo, where this error is much more likely
to cause trouble for a rather random reason: gccgo uses a
different layout of rtype, and in gccgo the kind field happens
to be the low byte of a pointer, not the high byte.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/155450044
The stack blowout can no longer happen,
but we can still test that too-complex regexps
are rejected.
Replacement for CL 162770043.
LGTM=iant, r
R=r, iant
CC=bradfitz, golang-codereviews
https://golang.org/cl/162860043
This is already tested by TestRE2Exhaustive, but the build has
not broken because that test is not run when using -test.short.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/155580043
https://golang.org/cl/152700045/ made it possible for struct literals assigned to globals to use <N> as the RHS. Normally, this is to zero out variables on first use. Because globals are already zero (or their linker initialized value), we just ignored this.
Now that <N> can occur from non-initialization code, we need to emit this code. We don't use <N> for initialization of globals any more, so this shouldn't cause any excessive zeroing.
Fixes#8961.
LGTM=rsc
R=golang-codereviews, rsc
CC=bradfitz, golang-codereviews
https://golang.org/cl/154540044
As we did with encoding, provide a trivial byte reader for
faster decoding. We can also reduce some of the copying
by doing the allocation all at once using a slightly different
interface from byte buffers.
benchmark old ns/op new ns/op delta
BenchmarkEndToEndPipe 13368 12902 -3.49%
BenchmarkEndToEndByteBuffer 5969 5642 -5.48%
BenchmarkEndToEndSliceByteBuffer 479485 470798 -1.81%
BenchmarkEncodeComplex128Slice 92367 92201 -0.18%
BenchmarkEncodeFloat64Slice 39990 38960 -2.58%
BenchmarkEncodeInt32Slice 30510 27938 -8.43%
BenchmarkEncodeStringSlice 33753 33365 -1.15%
BenchmarkDecodeComplex128Slice 232278 196704 -15.32%
BenchmarkDecodeFloat64Slice 150258 128191 -14.69%
BenchmarkDecodeInt32Slice 133806 115748 -13.50%
BenchmarkDecodeStringSlice 335117 300534 -10.32%
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/154360049
This adds a Reset() to compress/flate's decompressor and plumbs that through
to compress/zlib and compress/gzip's Readers so callers can avoid large
allocations when performing many inflate operations. In particular this
preserves the allocation of the decompressor.hist buffer, which is 32kb and
overwritten as needed while inflating.
On the benchmark described in issue 6317, produces the following speedup on
my 2.3ghz Intel Core i7 MBP with go version devel +6b696a34e0af Sun Aug 03
15:14:59 2014 -0700 darwin/amd64:
blocked.text w/out patch vs blocked.text w/ patch:
benchmark old ns/op new ns/op delta
BenchmarkGunzip 8371577533 7927917687 -5.30%
benchmark old allocs new allocs delta
BenchmarkGunzip 176818 148519 -16.00%
benchmark old bytes new bytes delta
BenchmarkGunzip 292184936 12739528 -95.64%
flat.text vs blocked.text w/patch:
benchmark old ns/op new ns/op delta
BenchmarkGunzip 7939447827 7927917687 -0.15%
benchmark old allocs new allocs delta
BenchmarkGunzip 90702 148519 +63.74%
benchmark old bytes new bytes delta
BenchmarkGunzip 9959528 12739528 +27.91%
Similar speedups to those bradfitz saw in https://golang.org/cl/13416045.
Fixes#6317.
Fixes#7950.
LGTM=nigeltao
R=golang-codereviews, bradfitz, dan.kortschak, adg, nigeltao, jamesr
CC=golang-codereviews
https://golang.org/cl/97140043
This is a day 1 error in the flag package: It did not check
that a flag was set at most once on the command line.
Because user-defined flags may have more general
properties, the check applies only to the standard flag
types in this package: bool, string, etc.
Fixes#8960.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/156390043
select {
case <- c:
case <- c:
}
In this case, c.recvq lists two SudoGs which have the same G.
So we can't use the G as the key to dequeue the correct SudoG,
as that key is ambiguous. Dequeueing the wrong SudoG ends up
freeing a SudoG that is still in c.recvq.
The fix is to use the actual SudoG pointer as the key.
LGTM=dvyukov
R=rsc, bradfitz, dvyukov, khr
CC=austin, golang-codereviews
https://golang.org/cl/159040043
Simple bug in argument processing: The final arg may
be the pipeline value, in which case it gets bound to the
fixed argument section. The code got that wrong. Easy
to fix.
Fixes#8950.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/161750043
Bytes buffers have more API and are a little slower. Since appending
is a key part of the path in encode, using a faster implementation
speeds things up measurably.
The couple of positive swings are likely garbage-collection related
since memory allocation looks different in the benchmark now.
I am not concerned by them.
benchmark old ns/op new ns/op delta
BenchmarkEndToEndPipe 6620 6388 -3.50%
BenchmarkEndToEndByteBuffer 3548 3600 +1.47%
BenchmarkEndToEndSliceByteBuffer 336678 367980 +9.30%
BenchmarkEncodeComplex128Slice 78199 71297 -8.83%
BenchmarkEncodeFloat64Slice 37731 32258 -14.51%
BenchmarkEncodeInt32Slice 26780 22977 -14.20%
BenchmarkEncodeStringSlice 35882 26492 -26.17%
BenchmarkDecodeComplex128Slice 194819 185126 -4.98%
BenchmarkDecodeFloat64Slice 120538 120102 -0.36%
BenchmarkDecodeInt32Slice 106442 107275 +0.78%
BenchmarkDecodeStringSlice 272902 269866 -1.11%
LGTM=ruiu
R=golang-codereviews, ruiu
CC=golang-codereviews
https://golang.org/cl/160990043
Use go generate to write better loops for decoding arrays,
just as we did for encoding. It doesn't help as much,
relatively speaking, but it's still noticeable.
benchmark old ns/op new ns/op delta
BenchmarkDecodeComplex128Slice 202348 184529 -8.81%
BenchmarkDecodeFloat64Slice 135800 120979 -10.91%
BenchmarkDecodeInt32Slice 121200 105149 -13.24%
BenchmarkDecodeStringSlice 288129 278214 -3.44%
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/154420044
Don't use cmd/pprof as it is not necessary installed
and does not work on nacl and plan9.
Instead just look at the raw profile.
LGTM=crawshaw, rsc
R=golang-codereviews, crawshaw, 0intro, rsc
CC=golang-codereviews
https://golang.org/cl/159010043
Better to avoid the memory loads and just use immediate constants.
This especially applies to zeroing, which was being done by
copying zeros from elsewhere in the binary, even if the value
was going to be completely initialized with non-zero values.
The zero writes were optimized away but the zero loads from
the data segment were not.
LGTM=r
R=r, bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/152700045
Replace i < 0 || i >= x with uint(i) >= uint(x).
Shorten a few other code sequences.
Move the kind bits to the bottom of the flag word, to avoid shifts.
LGTM=r
R=r, bradfitz
CC=golang-codereviews
https://golang.org/cl/159020043
We borrow a trick from the fmt package and avoid reflection
to walk the elements when possible. We could push further with
unsafe (and we may) but this is a good start.
Decode can benefit similarly; it will be done separately.
Use go generate (engen.go) to produce the helper functions
(enc_helpers.go).
benchmark old ns/op new ns/op delta
BenchmarkEndToEndPipe 6593 6482 -1.68%
BenchmarkEndToEndByteBuffer 3662 3684 +0.60%
BenchmarkEndToEndSliceByteBuffer 350306 351693 +0.40%
BenchmarkComplex128Slice 96347 80045 -16.92%
BenchmarkInt32Slice 42484 26008 -38.78%
BenchmarkFloat64Slice 51143 36265 -29.09%
BenchmarkStringSlice 53402 35077 -34.32%
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/156310043
gogo called from GC is okay
for the same reasons that
gogo called from System or ExternalCode is okay.
All three are fake stack traces.
Fixes#8408.
LGTM=dvyukov, r
R=r, dvyukov
CC=golang-codereviews
https://golang.org/cl/152580043
Dmitriy believes this broke Windows.
It looks like build.golang.org stopped before that,
but it's worth a shot.
««« original CL description
runtime: make pprof a little nicer
Update #8942
This does not fully address issue 8942 but it does make
the profiles much more useful, until that issue can be
fixed completely.
LGTM=dvyukov
R=r, dvyukov
CC=golang-codereviews
https://golang.org/cl/159990043
»»»
TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/160030043
hg was unable to create a CL on the code review server for this,
so I am submitting the merge by hand.
The only manual edits are in mgc0.c, to reapply the
removal of cached/ncached to the new code.
It cannot run 'go tool pprof'. There is no guarantee that's installed.
It needs to build a temporary pprof binary and run that.
It also needs to skip the test on systems that can't build and
run binaries, namely android and nacl.
See src/cmd/nm/nm_test.go's TestNM for a template.
Update #8867
Status: Accepted
TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/153710043
Update #8942
This does not fully address issue 8942 but it does make
the profiles much more useful, until that issue can be
fixed completely.
LGTM=dvyukov
R=r, dvyukov
CC=golang-codereviews
https://golang.org/cl/159990043
There are 3 issues:
1. Skip argument of callers is off by 3,
so that all allocations are deep inside of memory profiler.
2. Memory profiling statistics are not updated after runtime.GC.
3. Testing package does not update memory profiling statistics
before capturing the profile.
Also add an end-to-end test.
Fixes#8867.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/148710043
Both of these forms can avoid writing to the base pointer in x
(in the slice, always, and in the append, most of the time).
For Go 1.5, will need to change the compilation of x = x[0:y]
to avoid writing to the base pointer, so that the elision is safe,
and will need to change the compilation of x = append(x, ...)
to write to the base pointer (through a barrier) only when
growing the underlying array, so that the general elision is safe.
For Go 1.4, elide the write barrier always, a change that should
have equivalent performance characteristics but is much
simpler and therefore safer.
benchmark old ns/op new ns/op delta
BenchmarkBinaryTree17 3910526122 3918802545 +0.21%
BenchmarkFannkuch11 3747650699 3732600693 -0.40%
BenchmarkFmtFprintfEmpty 106 98.7 -6.89%
BenchmarkFmtFprintfString 280 269 -3.93%
BenchmarkFmtFprintfInt 296 282 -4.73%
BenchmarkFmtFprintfIntInt 467 470 +0.64%
BenchmarkFmtFprintfPrefixedInt 418 398 -4.78%
BenchmarkFmtFprintfFloat 574 535 -6.79%
BenchmarkFmtManyArgs 1768 1818 +2.83%
BenchmarkGobDecode 14916799 14925182 +0.06%
BenchmarkGobEncode 14110076 13358298 -5.33%
BenchmarkGzip 546609795 542630402 -0.73%
BenchmarkGunzip 136270657 136496277 +0.17%
BenchmarkHTTPClientServer 126574 125245 -1.05%
BenchmarkJSONEncode 30006238 27862354 -7.14%
BenchmarkJSONDecode 106020889 102664600 -3.17%
BenchmarkMandelbrot200 5793550 5818320 +0.43%
BenchmarkGoParse 5437608 5463962 +0.48%
BenchmarkRegexpMatchEasy0_32 192 179 -6.77%
BenchmarkRegexpMatchEasy0_1K 462 460 -0.43%
BenchmarkRegexpMatchEasy1_32 168 153 -8.93%
BenchmarkRegexpMatchEasy1_1K 1420 1280 -9.86%
BenchmarkRegexpMatchMedium_32 338 286 -15.38%
BenchmarkRegexpMatchMedium_1K 107435 98027 -8.76%
BenchmarkRegexpMatchHard_32 5941 4846 -18.43%
BenchmarkRegexpMatchHard_1K 185965 153830 -17.28%
BenchmarkRevcomp 795497458 798447829 +0.37%
BenchmarkTemplate 132091559 134938425 +2.16%
BenchmarkTimeParse 604 608 +0.66%
BenchmarkTimeFormat 551 548 -0.54%
LGTM=r
R=r, dave
CC=golang-codereviews, iant, khr, rlh
https://golang.org/cl/159960043
A new attack on CBC padding in SSLv3 was released yesterday[1]. Go only
supports SSLv3 as a server, not as a client. An easy fix is to change
the default minimum version to TLS 1.0 but that seems a little much
this late in the 1.4 process as it may break some things.
Thus this patch adds server support for TLS_FALLBACK_SCSV[2] -- a
mechanism for solving the fallback problem overall. Chrome has
implemented this since February and Google has urged others to do so in
light of yesterday's news.
With this change, clients can indicate that they are doing a fallback
connection and Go servers will be able to correctly reject them.
[1] http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
[2] https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/157090043
Among other things, *x = T{} does not need a write barrier.
The changes here avoid an unnecessary copy even when
no pointers are involved, so it may have larger effects.
In 6g and 8g, avoid manually repeated STOSQ in favor of
writing explicit MOVs, under the theory that the MOVs
should have fewer dependencies and pipeline better.
Benchmarks compare best of 5 on a 2012 MacBook Pro Core i5
with TurboBoost disabled. Most improvements can be explained
by the changes in this CL.
The effect in Revcomp is real but harder to explain: none of
the instructions in the inner loop changed. I suspect loop
alignment but really have no idea.
benchmark old new delta
BenchmarkBinaryTree17 3809027371 3819907076 +0.29%
BenchmarkFannkuch11 3607547556 3686983012 +2.20%
BenchmarkFmtFprintfEmpty 118 103 -12.71%
BenchmarkFmtFprintfString 289 277 -4.15%
BenchmarkFmtFprintfInt 304 290 -4.61%
BenchmarkFmtFprintfIntInt 507 458 -9.66%
BenchmarkFmtFprintfPrefixedInt 425 408 -4.00%
BenchmarkFmtFprintfFloat 555 555 +0.00%
BenchmarkFmtManyArgs 1835 1733 -5.56%
BenchmarkGobDecode 14738209 14639331 -0.67%
BenchmarkGobEncode 14239039 13703571 -3.76%
BenchmarkGzip 538211054 538701315 +0.09%
BenchmarkGunzip 135430877 134818459 -0.45%
BenchmarkHTTPClientServer 116488 116618 +0.11%
BenchmarkJSONEncode 28923406 29294334 +1.28%
BenchmarkJSONDecode 105779820 104289543 -1.41%
BenchmarkMandelbrot200 5791758 5771964 -0.34%
BenchmarkGoParse 5376642 5310943 -1.22%
BenchmarkRegexpMatchEasy0_32 195 190 -2.56%
BenchmarkRegexpMatchEasy0_1K 477 455 -4.61%
BenchmarkRegexpMatchEasy1_32 170 165 -2.94%
BenchmarkRegexpMatchEasy1_1K 1410 1394 -1.13%
BenchmarkRegexpMatchMedium_32 336 329 -2.08%
BenchmarkRegexpMatchMedium_1K 108979 106328 -2.43%
BenchmarkRegexpMatchHard_32 5854 5821 -0.56%
BenchmarkRegexpMatchHard_1K 185089 182838 -1.22%
BenchmarkRevcomp 834920364 780202624 -6.55%
BenchmarkTemplate 137046937 129728756 -5.34%
BenchmarkTimeParse 600 594 -1.00%
BenchmarkTimeFormat 559 539 -3.58%
LGTM=r
R=r
CC=golang-codereviews, iant, khr, rlh
https://golang.org/cl/157910047
A Go prototype can be used instead now, and the compiler
will do a better job than we will doing it by hand.
(We got it wrong in amd64p32, causing the current build
breakage.)
The auto-prototype-matching only applies to functions
without an explicit package path, so the TEXT lines for
reflectcall and callXX are s/runtime·/·/.
LGTM=khr
R=khr
CC=golang-codereviews, iant, r
https://golang.org/cl/153600043
The http package by default adds "Accept-Encoding: gzip" to outgoing
requests, unless it's a bad idea, or the user requested otherwise.
Only when the http package adds its own implicit Accept-Encoding header
does the http package also transparently un-gzip the response.
If the user requested part of a document (e.g. bytes 40 to 50), it appears
that Github/Varnish send:
range(gzip(content), 40, 50)
And not:
gzip(range(content, 40, 50))
The RFC 2616 set of replacements (with the purpose of
clarifying ambiguities since 1999) has an RFC about Range
requests (http://tools.ietf.org/html/rfc7233) but does not
mention the interaction with encodings.
Regardless of whether range(gzip(content)) or gzip(range(content)) is
correct, this change prevents the Go package from asking for gzip
in requests if we're also asking for Range, avoiding the issue.
If the user cared, they can do it themselves. But Go transparently
un-gzipping a fragment of gzip is never useful.
Fixes#8923
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/155420044
The assembler could give a better error, but this one
is good enough for now.
Fixes#8880.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/153610043
When the Import function in go/build encounters a directory
without any buildable Go source files, it returns a handy
NoGoError. Now if, instead it encounters multiple Go source files
from multiple packages, it returns a handy MultiplePackageError.
A new test for NoGoError and MultiplePackageError is also provided.
Fixes#8286.
LGTM=adg, rsc
R=bradfitz, rsc, adg
CC=golang-codereviews
https://golang.org/cl/155050043
The racewalk code was not updated for the new write barriers.
Make it more future-proof.
The new write barrier code assumed that +1 pointer would
be aligned properly for any type that might follow, but that's
not true on 32-bit systems where some types are 64-bit aligned.
The only system like that today is nacl/amd64p32.
Insert a dummy pointer so that the ambiguously typed
value is at +2 pointers, which is always max-aligned.
LGTM=r
R=r
CC=golang-codereviews, iant, khr
https://golang.org/cl/158890046
FieldByIndex never returns an invalid Value, so the validity
test can be avoided if the field is not indirect.
BenchmarkGobEncode 12768642 12424022 -2.70%
BenchmarkGobEncode 60.11 61.78 1.03x
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/158890045
includes undo of 22318cd31d7d and also:
- always use SetUnhandledExceptionFilter on windows-386;
- crash when receive EXCEPTION_BREAKPOINT in exception handler.
Fixes#8006.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/155360043
The inverse is defined whenever the element and the
modulus are relatively prime. The code already handles
this situation, but the spec does not.
Test that it does indeed work.
Fixes#8875
LGTM=agl
R=agl
CC=golang-codereviews
https://golang.org/cl/155010043
Assignments of 2-, 3-, and 4-word values were handled
by individual MOV instructions (and for scalars still are).
But if there are pointers involved, those assignments now
go through the write barrier routine. Before this CL, they
went to writebarrierfat, which calls memmove.
Memmove is too much overhead for these small
amounts of data.
Instead, call writebarrierfat{2,3,4}, which are specialized
for the specific amount of data being copied.
Today the write barrier does not care which words are
pointers, so size alone is enough to distinguish the cases.
If we keep these distinctions in Go 1.5 we will need to
expand them for all the pointer-vs-scalar possibilities,
so the current 3 functions will become 3+7+15 = 25,
still not a large burden (we deleted more morestack
functions than that when we dropped segmented stacks).
BenchmarkBinaryTree17 3250972583 3123910344 -3.91%
BenchmarkFannkuch11 3067605223 2964737839 -3.35%
BenchmarkFmtFprintfEmpty 101 96.0 -4.95%
BenchmarkFmtFprintfString 267 235 -11.99%
BenchmarkFmtFprintfInt 261 253 -3.07%
BenchmarkFmtFprintfIntInt 444 402 -9.46%
BenchmarkFmtFprintfPrefixedInt 374 346 -7.49%
BenchmarkFmtFprintfFloat 472 449 -4.87%
BenchmarkFmtManyArgs 1537 1476 -3.97%
BenchmarkGobDecode 13986528 12432985 -11.11%
BenchmarkGobEncode 13120323 12537420 -4.44%
BenchmarkGzip 451925758 437500578 -3.19%
BenchmarkGunzip 113267612 110053644 -2.84%
BenchmarkHTTPClientServer 103151 77100 -25.26%
BenchmarkJSONEncode 25002733 23435278 -6.27%
BenchmarkJSONDecode 94213717 82568789 -12.36%
BenchmarkMandelbrot200 4804246 4713070 -1.90%
BenchmarkGoParse 4646114 4379456 -5.74%
BenchmarkRegexpMatchEasy0_32 163 158 -3.07%
BenchmarkRegexpMatchEasy0_1K 433 391 -9.70%
BenchmarkRegexpMatchEasy1_32 154 138 -10.39%
BenchmarkRegexpMatchEasy1_1K 1481 1132 -23.57%
BenchmarkRegexpMatchMedium_32 282 270 -4.26%
BenchmarkRegexpMatchMedium_1K 92421 86149 -6.79%
BenchmarkRegexpMatchHard_32 5209 4718 -9.43%
BenchmarkRegexpMatchHard_1K 158141 147921 -6.46%
BenchmarkRevcomp 699818791 642222464 -8.23%
BenchmarkTemplate 132402383 108269713 -18.23%
BenchmarkTimeParse 509 478 -6.09%
BenchmarkTimeFormat 462 456 -1.30%
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/156200043
Comments lay out the concurrent GC algorithms.
This CL implements parts of the algorithm.
The acknowledgement code has been removed from this CL
LGTM=rsc, dvyukov
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/151540043
In [1] the behaviour of encoding/asn1 with respect to marshaling
optional integers was changed. Previously, a zero valued integer would
be omitted when marshaling. After the change, if a default value was
set then the integer would only be omitted if it was the default value.
This changed the behaviour of crypto/x509 because
Certificate.MaxPathLen has a default value of -1 and thus zero valued
MaxPathLens would no longer be omitted when marshaling. This is
arguably a bug-fix -- a value of zero for MaxPathLen is valid and
meaningful and now could be expressed. However it broke users
(including Docker) who were not setting MaxPathLen at all.
This change again causes a zero-valued MaxPathLen to be omitted and
introduces a ZeroMathPathLen member that indicates that, yes, one
really does want a zero. This is ugly, but we value not breaking users.
[1] https://code.google.com/p/go/source/detail?r=4218b3544610e8d9771b89126553177e32687adf
LGTM=rsc
R=rsc
CC=golang-codereviews, golang-dev
https://golang.org/cl/153420045
This error is returned by lib9p when removing a file
without parent. It should fix TestRemoveAllRace
when running on ramfs.
LGTM=bradfitz, aram
R=rsc, bradfitz, aram
CC=golang-codereviews, mischief
https://golang.org/cl/153410044
The code for a generated type is already generating an
unrolled GC bitmask. Rather than unrolling the the source
type bitmasks and copying them, just generate the required
bitmask directly. Don't mark it as an unrolled GC program,
since there is no need to do so.
Fixes#8917.
LGTM=rsc
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/156930044
Our current pe object reader assumes that every symbol starting with
'.' is section. It appeared to be true, until now gcc 4.9.1 generates
some symbols with '.' at the front. Change that logic to check other
symbol fields in addition to checking for '.'. I am not an expert
here, but it seems reasonable to me.
Added test, but it is only good, if tested with gcc 4.9.1. Otherwise
the test PASSes regardless.
Fixes#8811.
Fixes#8856.
LGTM=jfrederich, iant, stephen.gutekanst
R=golang-codereviews, jfrederich, stephen.gutekanst, iant
CC=alex.brainman, golang-codereviews
https://golang.org/cl/152410043
gcc 4.9.1 generates pe sections with names longer then 8 charters.
From IMAGE_SECTION_HEADER definition:
Name
An 8-byte, null-padded UTF-8 string. There is no terminating null character
if the string is exactly eight characters long. For longer names, this
member contains a forward slash (/) followed by an ASCII representation
of a decimal number that is an offset into the string table.
Our current pe object file reader does not read string table when section
names starts with /. Do that, so (issue 8811 example)
c:\go\path\src\isssue8811>go build
# isssue8811
isssue8811/glfw(.text): isssue8811/glfw(/76): not defined
isssue8811/glfw(.text): undefined: isssue8811/glfw(/76)
becomes
c:\go\path\src\isssue8811>go build
# isssue8811
isssue8811/glfw(.text): isssue8811/glfw(.rdata$.refptr._glfwInitialized): not defined
isssue8811/glfw(.text): undefined: isssue8811/glfw(.rdata$.refptr._glfwInitialized)
Small progress to
Update #8811
LGTM=iant, jfrederich
R=golang-codereviews, iant, jfrederich
CC=golang-codereviews
https://golang.org/cl/154210044
I diffed the output of `nm -n gofmt' before and after this change,
and verified that all changes are correct and all corrupted symbol
names are fixed.
Fixes#8906.
LGTM=iant, cookieo9
R=golang-codereviews, iant, cookieo9
CC=golang-codereviews
https://golang.org/cl/159750043
https://golang.org/cl/153770043/ tried to fix the case where a
implicitly tagged Time, that happened to have the same tag as
GENERALIZEDTIME, shouldn't be parsed as a GENERALIZEDTIME.
It did so, mistakenly, by testing whether params.tag != nil. But
explicitly tagged values also have a non-nil tag and there the inner
tag actually does encode the type of the value.
This change instead tests whether the tag class is UNIVERSAL before
assuming that the tag contains type information.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/152380044
That was complete failure - builders are broken,
but original cl worked fine on my system.
I will need access to builders
to test this change properly.
««« original CL description
runtime: handle all windows exception
Fixes#8006.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/145150043
»»»
TBR=rsc
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/154180043
In channels, zeroing of gp.waiting is missed on a closed channel panic.
m.morebuf.g is not zeroed.
I don't expect the latter causes any problems, but just in case.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/151610043
TestMakeFuncVariadic only called the variadic function via Call and
CallSlice, not via a direct function call.
I thought these tests would fail under gccgo tip, but they don't. Still seems worth having though.
LGTM=iant
R=golang-codereviews, gobot, iant
CC=golang-codereviews
https://golang.org/cl/152060043
This change prevents confusion in the garbage collector.
The collector wants to make sure that every pointer it finds
isn't junk. Its criteria for junk is (among others) points
to a "free" span.
Because the stack shrinker modifies pointers in the heap,
there is a race condition between the GC scanner and the
shrinker. The GC scanner can see old pointers (pointers to
freed stacks). In particular this happens with SudoG.elem
pointers.
Normally this is not a problem, as pointers into stack spans
are ok. But if the freed stack is the last one in its span,
the span is marked as "free" instead of "contains stacks".
This change makes sure that even if the GC scanner sees
an old pointer, the span into which it points is still
marked as "contains stacks", and thus the GC doesn't
complain about it.
This change will make the GC pause a tiny bit slower, as
the stack freeing now happens in serial with the mark pause.
We could delay the freeing until the mutators start back up,
but this is the simplest change for now.
TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/158750043
These tests fail when using gccgo. In gccgo using Interface
on the value of a method function is implemented using a
variant of MakeFunc. That approach did not correctly handle
variadic functions.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/151280043
The change contains 3 spot optimizations to scan loop:
1. Don't use byte vars, use uintptr's instead.
This seems to alleviate some codegen issue,
and alone accounts to a half of speedup.
2. Remove bitmap cache. Currently we cache only 1 byte,
so caching is not particularly effective anyway.
Removal of the cache simplifies code and positively affects regalloc.
3. Replace BitsMultiword switch with if and
do debug checks only in Debug mode.
I've benchmarked changes separately and ensured that
each of them provides speedup on top of the previous one.
This change as a whole fixes the unintentional regressions
of scan loop that were introduced during development cycle.
Fixes#8625.
Fixes#8565.
On go.benchmarks/garbage benchmark:
GOMAXPROCS=1
time: -3.13%
cputime: -3.22%
gc-pause-one: -15.71%
gc-pause-total: -15.71%
GOMAXPROCS=32
time: -1.96%
cputime: -4.43%
gc-pause-one: -6.22%
gc-pause-total: -6.22%
LGTM=khr, rsc
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/153990043
Out of stack space due to new 2-word call in freedefer.
Go back to smaller function calls.
TBR=brainman
CC=golang-codereviews
https://golang.org/cl/152340043
It appears to be an opaque bit pattern more than a pointer.
The Go garbage collector has discovered that for m0
it is set to 0x4c.
Should fix Windows build.
TBR=brainman
CC=golang-codereviews
https://golang.org/cl/149640043
Another dangling stack pointer in a cached structure.
Same as SudoG.elem and SudoG.selectdone.
Definitely a fix, and the new test in freedefer makes the
crash reproducible, but probably not a complete fix.
I have seen one dangling pointer in a Defer.panic even
after this fix; I cannot see where it could be coming from.
I think this will fix the solaris build.
I do not think this will fix the occasional failure on the darwin build.
TBR=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/155080043
This avoids a pop-up box on OS X and it avoids
a test failure if something is using 5555.
I apologize for not noticing this during the review.
TBR=r
CC=golang-codereviews
https://golang.org/cl/152320044
It seems reasonable that people might want to look up the
ImportComment with "go list".
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/143600043
I have a CL which at every gc looks through data and bss
sections for nonpointer data (according to gc maps) that
looks like a pointer. These are potential missing roots.
The only thing it finds are begnign, storing stack pointers
into m0.scalararg[1] and never cleaning them up. Let's
clean them up now so the test CL passes all.bash cleanly.
The test CL can't be checked in because we might store
pointer-looking things in nonpointer data by accident.
LGTM=iant
R=golang-codereviews, iant, khr
CC=golang-codereviews
https://golang.org/cl/153210043
We no longer have full type information in the heap, so
we can't dump that any more. Instead we dump ptr/noptr
maps so at least we can compute graph connectivity.
In addition, we still dump Iface/Eface types so together
with dwarf type info we might be able to reconstruct
types of most things in the heap.
LGTM=dvyukov
R=golang-codereviews, dvyukov, rsc, khr
CC=golang-codereviews
https://golang.org/cl/155940043
This will help find bugs during the release freeze.
It's not clear it should be kept for the release itself.
That's issue 8861.
The most likely thing that would trigger this is stale
pointers that previously were ignored or caused memory
leaks. These were allowed due to the use of conservative
collection. Now that everything is precise, we should not
see them anymore.
The small number check reinforces what the stack copier
is already doing, catching the storage of integers in pointers.
It caught issue 8864.
The check is disabled if _cgo_allocate is linked into the binary,
which is to say if the binary is using SWIG to allocate untyped
Go memory. In that case, there are invalid pointers and there's
nothing we can do about it.
LGTM=rlh
R=golang-codereviews, dvyukov, rlh
CC=golang-codereviews, iant, khr, r
https://golang.org/cl/148470043
Depending on flags&KindGCProg,
gc[0] and gc[1] are either pointers or inlined bitmap bits.
That's not compatible with a precise garbage collector:
it needs to be always pointers or never pointers.
Change the inlined bitmap case to store a pointer to an
out-of-line bitmap in gc[0]. The out-of-line bitmaps are
dedup'ed, so that for example all pointer types share the
same out-of-line bitmap.
Fixes#8864.
LGTM=r
R=golang-codereviews, dvyukov, r
CC=golang-codereviews, iant, khr, rlh
https://golang.org/cl/155820043
http.Client calls URL.String() to fill in the Referer header, which may
contain authentication info. This patch removes authentication info from
the Referer header without introducing any API changes.
A new test for net/http is also provided.
This is the polished version of Alberto García Hierro's
https://golang.org/cl/9766046/
It should handle https Referer right.
Fixes#8417
LGTM=bradfitz
R=golang-codereviews, gobot, bradfitz, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/151430043
http://build.golang.org/log/c7a91b6eac8f8daa2bd17801be273e58403a15f2
# cmd/pprof
/linux-386-clang-9115aad1dc4a/go/pkg/linux_386/net.a(_all.o): sym#16: ignoring .Linfo_string0 in section 16 (type 0)
/linux-386-clang-9115aad1dc4a/go/pkg/linux_386/net.a(_all.o): sym#17: ignoring .Linfo_string1 in section 16 (type 0)
/linux-386-clang-9115aad1dc4a/go/pkg/linux_386/net.a(_all.o): sym#18: ignoring .Linfo_string2 in section 16 (type 0)
/linux-386-clang-9115aad1dc4a/go/pkg/linux_386/net.a(_all.o): sym#20: ignoring .Linfo_string0 in section 16 (type 0)
/linux-386-clang-9115aad1dc4a/go/pkg/linux_386/net.a(_all.o): sym#21: ignoring .Linfo_string1 in section 16 (type 0)
...
I don't know what these are. Let's ignore them and see if we get any further.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/155030043
Noticed while reviewing https://golang.org/cl/147690043/
I'd never seen anybody use IndexRune before, and
unsurprisingly it doesn't use the other fast paths in the
strings/bytes packages. IndexByte uses assembly.
Also, less code this way.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/147700043
A file name must have a non-empty underscore-separated
prefix before its suffix matches GOOS. This is what the
documentation already said but is not what the code did.
Fixes#8838.
This needs to be called out in the release notes.
The he single affected file
code.google.com/p/go.text/collate/tools/colcmp/darwin.go
could use a renaming but works because it has a build tag inside.
LGTM=adg, rsc
R=golang-codereviews, adg, rsc
CC=golang-codereviews
https://golang.org/cl/147690043
The internal comments are not completely precise about
what is going on, and they are causing confusion.
Fixes#8283.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/151460043
While we're here, fix the implementation of Release on both
Unix and Windows: Release is supposed to make Signal an error.
While we're here, make sure we never Signal pid 0.
(Don't try this at home.)
Fixes#7658.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews, iant
https://golang.org/cl/152240043
For example, fixes 'go vet syscall', which has source
files in package syscall_test.
Fixes#8511.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews, iant
https://golang.org/cl/152220044
At last minute before 1.3 we relaxed SetFinalizer to avoid
crashes when you pass the result of a global alloc to it.
This avoids the crash but makes SetFinalizer a bit too relaxed.
Document that the finalizer of a global allocation may not run.
Tighten the SetFinalizer check to ignore a global allocation but
not ignore everything else.
Fixes#7656.
LGTM=r, iant
R=golang-codereviews, iant, r
CC=dvyukov, golang-codereviews, khr, rlh
https://golang.org/cl/145930043
This test is flaky, just like TestDualStackTCPListener.
That one was disabled. Disable this one too.
Update #5001
LGTM=bradfitz
R=rlh, bradfitz
CC=golang-codereviews
https://golang.org/cl/154950043
This approach was suggested in
https://golang.org/cl/138250043/#msg15.
Unlike current version of mksyscall_windows.go,
new code could be used in go.sys and other external
repos without help from asm.
LGTM=iant
R=golang-codereviews, iant, r
CC=golang-codereviews
https://golang.org/cl/143160046
It was inconsistent.
Also test these better.
Also document the default format for types.
This wasn't written down.
Fixes#8470.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/154870043
The test doesn't work with GOTRACEBACK != 2.
Diagnose that failure mode.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/152970043
Apply a similar transformation to %+v that we did to %#v, making it
a top-level setting separate from the + flag itself. This fixes the
appearance of flags in Formatters and cleans up the code too,
probably making it a little faster.
Fixes#8835.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/154820043
Removes another dangling pointer that might
cause a memory leak in 1.4 or crash the GC in 1.5.
LGTM=rlh
R=golang-codereviews
CC=golang-codereviews, iant, khr, r, rlh
https://golang.org/cl/150520043
This change was necessary on the dev.garbage branch
to keep the garbage collector from seeing pointers into
invalid heap areas.
On this default (Go 1.4) branch, the change removes
some possibility for memory leaks.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, iant, r, rlh
https://golang.org/cl/155760043
Structs without tags have no unique name to use in the
Go definitions generated from the C types.
This caused issue 8812, fixed by CL 149260043.
Avoid future problems by requiring struct tags.
Update runtime as needed.
(There is no other C code in the tree.)
LGTM=bradfitz, iant
R=golang-codereviews, bradfitz, dave, iant
CC=golang-codereviews, khr, r
https://golang.org/cl/150360043
Refactoring of the scan and mark phase so that concurrent GC,
in particular the write barrier, can share a common infrastructure.
Now that the scan and mark phases have been separated
we will be able to scan stacks without blackening any objects.
This in turn will allow us to delay installing expensive write barrier code.
LGTM=rsc
R=rsc, khr, dvyukov
CC=golang-codereviews
https://golang.org/cl/145640044
I will use different approach to solve this problem.
See CL 143160046 for details.
««« original CL description
syscall: keep Windows syscall pointers live too
Like https://golang.org/cl/139360044
LGTM=rsc, alex.brainman
R=alex.brainman, rsc
CC=golang-codereviews
https://golang.org/cl/138250043
»»»
LGTM=r
R=golang-codereviews, bradfitz, r
CC=golang-codereviews
https://golang.org/cl/147440043
The %#v verb is special: it says all values below need to print as %#v.
However, for some situations the # flag has other meanings and this
causes some issues, particularly in how Formatters work. Since %#v
dominates all formatting, translate it into actual state of the formatter
and decouple it from the # flag itself within the calculations (although
it must be restored when methods are doing the work.)
The result is cleaner code and correct handling of # for Formatters.
TODO: Apply the same thinking to the + flag in a followup CL.
Also, the wasString return value in handleMethods is always false,
so eliminate it.
Update #8835
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/146650043
In old conservative Go, this could cause memory leaks.
A new pickier collector might reasonably crash when it saw one of these.
LGTM=rlh
R=rlh
CC=golang-codereviews
https://golang.org/cl/147480043
The documentation states that Exp(x, y, m)
computes x**y mod |m| for m != nil && m > 0.
In math.big, Mod is the Euclidean modulus,
which is always >= 0.
Fixes#8822.
LGTM=agl, r, rsc
R=agl, r, rsc
CC=golang-codereviews
https://golang.org/cl/145650043
Not found because it was not used by name.
Add name in comments for what's left behind.
LGTM=rlh
R=rlh
CC=golang-codereviews
https://golang.org/cl/148430043
envi needs to be updated during Setenv so the key can be correctly deleted later with Unsetenv.
Update #8849.
LGTM=0intro
R=bradfitz, 0intro
CC=golang-codereviews
https://golang.org/cl/149300046
This new text won't stop the whining but it might focus the whining a little more.
LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/146680044
This thing should never be called, but before
151960044 it was being called, incorrectly.
This is now just a precaution but let's pretend it
Fixes#8843
even though that was fixed by 151960044.
The test case was already there and ran, another mystery.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/151970043
The nicest solution would be to buffer the message and only write
it if it encodes correctly, but that adds considerable memory and
CPU overhead for a very rare condition. Instead, we just shut
down the connection if this happens.
Fixes#7689.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/146670043
The ASN.1 encoding of the CRL Distribution Points extension showed an invalid false 'IsCompound' which caused a display problem in the Windows certificate viewer.
LGTM=agl
R=agl
CC=golang-codereviews
https://golang.org/cl/143320043
+ static test
NB: there's a preexisting (dynamic) failure of test issue7978.go.
LGTM=iant
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/144650045
This is a minor cleanup following CL 142360043:
The internal parse and format functions in both packages
were almost identical - made them identical by adding an
extra parameter, and documented them as identical.
Eventually we should find a nice way to factor these functions
out, but we cannot do this now while in prep for 1.4.
No functionality change.
LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/146520043
Bodies larger than 8KB (the default bufio reader size) weren't
being dumped. Force a read of the body so they're teed into
the response buffer.
Thanks to Steven Hartland for identifying the problem.
Fixes#8089
LGTM=r
R=golang-codereviews, r
CC=adg, golang-codereviews
https://golang.org/cl/144650044
Not a language change.
Several inaccuracies were fixed:
1) A variable declaration may declare more than just one
variable.
2) Variable initialization follows the rules of assignments,
including n:1 assignments. The existing wording implied a 1:1
or n:n rule and generally was somewhat unspecific.
3) The rules for variable declarations with no types and
untyped initialization expressions had minor holes (issue 8088).
4) Clarified the special cases of assignments of untyped values
(we don't just have untyped constants, but also untyped bools,
e.g. from comparisons). The new wording is more direct.
To that end, introduced the notion of an untyped constant's
"default type" so that the same concept doesn't have to be
repeatedly introduced.
Fixes#8088.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/142320043
Right now it is always pkgname.test.exe, but if pkgname is
patch or install or setup or update, Windows thinks that
running it will install new software, so it pops up a dialog
box asking for more permission.
Renaming the binary avoids the Windows security check.
This only applies to the binary that the Go command writes
to its temporary work directory. If the user runs 'go test -c'
or any of the other ways to generate a test binary, it will
continue to use pkgname.test.exe.
Fixes#8711.
LGTM=bradfitz
R=golang-codereviews, r
CC=alex.brainman, bradfitz, golang-codereviews, iant
https://golang.org/cl/146580043
Update #8798
This is a new implementation of pprof,
written in Go instead of in Perl.
It was written primarily by Raul Silvera and
is in use for profiling programs of all languages
inside Google.
The internal structure is a bit package-heavy,
but it matches the copy used inside Google, and
since it is in an internal directory, we can make
changes to it later if we need to.
The only "new" file here is src/cmd/pprof/pprof.go,
which stitches together the Google pprof and the
Go command libraries for object file access.
I am explicitly NOT interested in style or review
comments on the rest of the files
(that is, src/cmd/pprof/internal/...).
Those are intended to stay as close to the Google
copies as possible, like we did with the pprof Perl script.
Still to do:
- Basic tests.
- Real command documentation.
- Hook up disassemblers.
LGTM=r
R=r, bradfitz, alex.brainman, dave
CC=golang-codereviews
https://golang.org/cl/153750043
For Go 1.3 these external packages were collapsed into
large single-file implementations stored in the cmd/objdump
directory.
For Go 1.4 we want pprof to be able to link against them too,
so move them into cmd/internal, where they can be shared.
The new files are copied from the repo in the file path (rsc.io/...).
Those repos were code reviewed during development
(mainly by crawshaw and minux), because we knew the
main repo would use them.
Update #8798
LGTM=bradfitz
R=crawshaw, bradfitz
CC=golang-codereviews
https://golang.org/cl/153750044
GC types were not being generated for the garbage collector
work buffer. The markfor object was being collected as a result.
This broke amd64p32 and maybe plan9 builds. Why it didn't break
every build I'm not sure...
Fixes#8812
LGTM=0intro, rsc
R=golang-codereviews, dave, khr, 0intro, rsc
CC=golang-codereviews
https://golang.org/cl/149260043
Our traceback code needs to know the PC of several special
functions, including goexit, mcall, etc. Make sure that
these PCs are initialized before any traceback occurs.
Fixes#8766
LGTM=rsc
R=golang-codereviews, rsc, khr, bradfitz
CC=golang-codereviews
https://golang.org/cl/145570043
See comment 4 of https://code.google.com/p/go/issues/detail?id=8483#c4:
"So if a user creates a http.Client, issues a bunch of
requests and then wants to shutdown it and all opened connections;
what is she intended to do? The report suggests that just waiting for
all pending requests and calling CloseIdleConnections won't do, as
there can be new racing connections. Obviously she can't do what
you've done in the test, as it uses the unexported function. If this
happens periodically, it can lead to serious resource leaks (the
transport is also preserved alive). Am I missing something?"
This CL tracks the user's intention to close all idle
connections (CloseIdleConnections sets it true; and making a
new request sets it false). If a pending dial finishes and
nobody wants it, before it's retained for a future caller, the
"wantIdle" bool is checked and it's closed if the user has
called CloseIdleConnections without a later call to make a new
request.
Fixes#8483
LGTM=adg
R=golang-codereviews, dvyukov, adg
CC=golang-codereviews, rsc
https://golang.org/cl/148970043
Fixes#5551.
Fixes#4449.
Adds tests for both issues.
Note that the two issues occur only when formatting partial Go code
with indent.
The best way to understand the change is as follows: I took the code
of cmd/gofmt and go/format, combined it into one unified code that
does not suffer from either 4449 nor 5551, and then applied that code
to both cmd/gofmt and go/format.
As a result, there is now much more identical code between the two
packages, making future code deduplication easier (it was not possible
to do that now without adding public APIs, which I was advised not to
do at this time).
More specifically, I took the parse() of cmd/gofmt which correctly
preserves comments (issue 5551) and modified it to fix issue where
it would sometimes modify literal values (issue 4449).
I ended up removing the matchSpace() function because it no longer
needed to do some of its work (insert indent), and a part of its work
had to be done in advance (determining the indentation of first code
line), because that calculation is required for cfg.Fprint() to run.
adjustIndent is used to adjust the indent of cfg.Fprint() to compensate
for the body of wrapper func being indented by one level. This allows
to get rid of the bytes.Replace text manipulation of inner content,
which was problematic and sometimes altered raw string literals (issue
4449). This means that sometimes the value of cfg.Indent is negative,
but that works as expected.
So now the algorithm for formatting partial Go code is:
1. Determine and prepend leading space of original source.
2. Determine and prepend indentation of first code line.
3. Format and write partial Go code (with all of its leading &
trailing space trimmed).
4. Determine and append trailing space of original source.
LGTM=gri
R=golang-codereviews, bradfitz, gri
CC=golang-codereviews
https://golang.org/cl/142360043
Fixes#8690.
This CL moves the save of LR around BL runtime.read_tls_fallback to liblink as it is not needed when MRC is not replaced.
LGTM=rsc, minux
R=rsc, khr, minux
CC=golang-codereviews
https://golang.org/cl/147310043
On android, root certificates appear to be stored in the folder
/system/etc/security/cacerts, which has many certs in several
different files. This change adds a new array of directories in
which certs can be found.
To test this, I simply tried making a request with the http
library to an HTTPS URL on an android emulator and manually
verified that it worked.
LGTM=crawshaw
R=golang-codereviews, gobot, crawshaw
CC=golang-codereviews
https://golang.org/cl/151800043
We're not comparing with code addresses any more. Instead,
we use nil algorithm functions to mark uncomparable types.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/151040044
CL 149110043 changed yacc to no longer keep a leading space
for quoted tokens. That is OK by itself but unfortunately
yacc was relying on that leading space to notice which tokens
it should not output as const declarations.
Add a few such tokens to expr.y, although it won't make any
immediate difference as we seem to have no tests for yacc.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/152720043
Unnecessary; covered by https://golang.org/cl/141690043
Verified by jonathan@titanous.com on golang-dev.
««« original CL description
cmd/ld: close outfile before cleanup
This prevents the temporary directory from being leaked when
the linker is run on a FUSE filesystem.
Fixes#8684.
LGTM=bradfitz
R=golang-codereviews, rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/141840043
»»»
LGTM=jonathan, iant
R=iant, jonathan
CC=golang-codereviews
https://golang.org/cl/150250045
The existing spec rules on package initialization were
contradictory: They specified that 1) dependent variables
are initialized in dependency order, and 2) independent
variables are initialized in declaration order. This 2nd
rule cannot be satisfied in general. For instance, for
var (
c = b + 2
a = 0
b = 1
)
because of its dependency on b, c must be initialized after b,
leading to the partial order b, c. Because a is independent of
b but is declared before b, we end up with the order: a, b, c.
But a is also independent of c and is declared after c, so the
order b, c, a should also be valid in contradiction to a, b, c.
The new rules are given in form of an algorithm which outlines
initialization order explicitly.
gccgo and go/types already follow these rules.
Fixes#8485.
LGTM=iant, r, rsc
R=r, rsc, iant, ken, gordon.klaus, adonovan
CC=golang-codereviews
https://golang.org/cl/142880043
This prevents the temporary directory from being leaked when
the linker is run on a FUSE filesystem.
Fixes#8684.
LGTM=bradfitz
R=golang-codereviews, rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/141840043
This fixes the bug in which the linker reports "missing Go
type information" when a -X option refers to a symbol that is
not used.
Fixes#8821.
LGTM=rsc
R=rsc, r
CC=golang-codereviews
https://golang.org/cl/151000043
The extra-clever code in Sincos is trying to do
if v&2 == 0 {
mask = 0xffffffffffffffff
} else {
mask = 0
}
It does this by turning v&2 into a float64 X0 and then using
MOVSD $0.0, X3
CMPSD X0, X3, 0
That CMPSD is defined to behave like:
if X0 == X3 {
X3 = 0xffffffffffffffff
} else {
X3 = 0
}
which gives the desired mask in X3. The goal in using the
CMPSD was to avoid a conditional branch.
This code fails when called from a PortAudio callback.
In particular, the failure behavior is exactly as if the
CMPSD always chose the 'true' execution.
Notice that the comparison X0 == X3 is comparing as
floating point values the 64-bit pattern v&2 and the actual
floating point value zero. The only possible values for v&2
are 0x0000000000000000 (floating point zero)
and 0x0000000000000002 (floating point 1e-323, a denormal).
If they are both comparing equal to zero, I conclude that
in a PortAudio callback (whatever that means), the processor
is running in "denormals are zero" mode.
I confirmed this by placing the processor into that mode
and running the test case in the bug; it produces the
incorrect output reported in the bug.
In general, if a Go program changes the floating point math
modes to something other than what Go expects, the math
library is not going to work exactly as intended, so we might
be justified in not fixing this at all.
However, it seems reasonable that the client code might
have expected "denormals are zero" mode to only affect
actual processing of denormals. This code has produced
what is in effect a gratuitous denormal by being extra clever.
There is nothing about the computation being requested
that fundamentally requires a denormal.
It is also easy to do this computation in integer math instead:
mask = ((v&2)>>1)-1
Do that.
For the record, the other math tests that fail if you put the
processor in "denormals are zero" mode are the tests for
Frexp, Ilogb, Ldexp, Logb, Log2, and FloatMinMax, but all
fail processing denormal inputs. Sincos was the only function
for which that mode causes incorrect behavior on non-denormal inputs.
The existing tests check that the new assembly is correct.
There is no test for behavior in "denormals are zero" mode,
because I don't want to add assembly to change that.
Fixes#8623.
LGTM=josharian
R=golang-codereviews, josharian
CC=golang-codereviews, iant, r
https://golang.org/cl/151750043
go test's handling of _test.go files when the entire
package's set of files has no Test functions has varied
over the past few releases. There are a few interesting
cases (all contain no Test functions):
(1) x_test.go has syntax errors
(2) x_test.go has type errors
(3) x_test.go has runtime errors (say, a func init that panics)
In Go 1.1, tests with (1) or (2) failed; (3) passed.
In Go 1.2, tests with (1) or (2) failed; (3) passed.
In Go 1.3, tests with (1) failed; (2) or (3) passed.
After this CL, tests with (1), (2), or (3) all fail.
This is clearly a corner case, but it seems to me that
the behavior of the test should not change if you
add or remove a line like
func TestAlwaysPasses(t *testing.T) {}
That implies that the _test.go files must always
be built and always be imported into the test binary.
Doing so means that (1), (2), and (3) must all fail.
Fixes#8337.
LGTM=iant
R=golang-codereviews, iant
CC=adg, golang-codereviews, r
https://golang.org/cl/150980043
From issue 7967 I learned:
1) yacc accepts either 'x' or "x" to mean token value 0x78
2) yacc also accepts 'xyz' and "XYZ" to mean token value 0x78
Use strconv.Unquote to simplify the handling of quoted
strings and check that each has only one rune.
Although this does clean things up, it makes 'x' and "x"
treated as different internally (now they are stored as
`'x'` and `"x"`; before they were both ` x`). Grammars that
use both interchangeably will now die with an error
similar to the one from issue 7967:
yacc bug -- cannot have 2 different Ts with same value
"+" and '+'
The echoing of the quotes should make clear what is going on.
The other semantic change caused by using strconv.Unquote
is that '\"' and "\'" are no longer valid. Like in Go, they must be
spelled without the backslash: '"' and "'".
On the other hand, now yacc and Go agree about what character
and string literals mean.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/149110043
The one line that you can't test easily was broken.
This manifested as a failure of a pre-existing test
in test.bash but I didn't notice it (there are a few other
long-standing failures that need to be fixed).
TBR=r
CC=golang-codereviews
https://golang.org/cl/146340044
Today, 'go build -a my/pkg' and 'go install -a my/pkg'
recompile not just my/pkg and all its dependencies that
you wrote but also the standard library packages.
Recompiling the standard library is problematic on
some systems because the installed copy is not writable.
The -a behavior means that you can't use 'go install -a all'
or 'go install -a my/...' to rebuild everything after a Go
release - the rebuild stops early when it cannot overwrite
the installed standard library.
During development work, however, you do want install -a
to rebuild everything, because anything might have changed.
Resolve the conflict by making the behavior of -a depend
on whether we are using a released copy of Go or a devel copy.
In the release copies, -a no longer applies to the standard library.
In the devel copies, it still does.
This is the latest in a long line of refinements to the
"do I build this or not" logic. It is surely not the last.
Fixes#8290.
LGTM=r
R=golang-codereviews, r, tracey.brendan
CC=adg, golang-codereviews, iant
https://golang.org/cl/151730045
This fixes the test/linkx.go test, which does not run by default.
(Issue 4139 is about fixing that.)
Fixes#8806.
LGTM=r
R=golang-codereviews, r
CC=bradfitz, golang-codereviews, iant
https://golang.org/cl/145420043
Also rebuild doc.go; was stale, so contains extra changes.
Fixes#8677.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews, iant
https://golang.org/cl/148170043
While we are here, remove undocumented, meaningless test -file flag.
Fixes#7724.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews, iant
https://golang.org/cl/149070043
Fix by atom (from CL 89190044), comment and test by me.
Fixes#6823.
LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=0xe2.0x9a.0x9b, adg, golang-codereviews, iant, r
https://golang.org/cl/148180043
If you say 'go get -v' you get extra information when import
paths are not of the expected form.
If you say 'go get -v src/rsc.io/pdf' the message says that
src/rsc.io/pdf does not contain a hostname, which is incorrect.
The problem is that it does not begin with a hostname.
Fixes#7432.
LGTM=r
R=golang-codereviews, r
CC=bradfitz, golang-codereviews, iant
https://golang.org/cl/144650043
If you do 'go get -u rsc.io/pdf' and then rsc.io/pdf's redirect
changes to point somewhere else, after this CL a later
'go get -u rsc.io/pdf' will tell you that.
Fixes#8548.
LGTM=iant
R=golang-codereviews, iant
CC=adg, golang-codereviews, n13m3y3r, r
https://golang.org/cl/147170043
The pattern was only working if the checkout had
already been done, but the code was trying to make
it work even the first time. Test and fix.
Fixes#8335.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews, iant
https://golang.org/cl/146310043
This means I won't have to edit the plugin when I create
the next dev branch.
LGTM=r, adg
R=r, adg
CC=golang-codereviews
https://golang.org/cl/148950045
Need to restore the g register. Somehow this line vaporized from
CL 144130043. Also cgo_topofstack -> _cgo_topofstack, that vaporized also.
TBR=rsc
CC=golang-codereviews
https://golang.org/cl/150940044
During a cgo call, the stack can be copied. This copy invalidates
the pointer that cgo has into the return value area. To fix this
problem, pass the address of the location containing the stack
top value (which is in the G struct). For cgo functions which
return values, read the stktop before and after the cgo call to
compute the adjustment necessary to write the return value.
Fixes#8771
LGTM=iant, rsc
R=iant, rsc, khr
CC=golang-codereviews
https://golang.org/cl/144130043
Not sure why they used empty.s and all these other
packages were special cased in cmd/go instead.
Add them to the list.
This avoids problems with net .s files being compiled
with gcc in cgo mode and gcc not supporting // comments
on ARM.
Not a problem with bytes, but be consistent.
The last change fixed the ARM build but broke the Windows build.
Maybe *this* will make everyone happy. Sigh.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/144530046
In cgo mode it gets passed to gcc, and on ARM
it appears that gcc does not support // comments.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/142640043
Fixes linux builds (_vdso); may fix others.
I can at least cross-compile cmd/go for every
implemented system now.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/142630043
Should fix the Windows build. Untested.
on Windows, args are made by src/os/exec_windows.go, not package runtime.
runtime·goargs has if(Windows) return;
The two init funcs in pkg os were conflicting, with the second
overwriting Args back to an empty slice.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/143540044
Corrections due to new strict type rules for data+bss.
Also disable misc/cgo/cdefstest since you can't compile C code anymore.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/148050044
Previous behavior was undocumented and inconsistent. Now it is documented
and consistent and measures the input size, since that makes more sense
when talking about %q and %x. For %s the change has no effect.
Fixes#8151.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/144540044
In linker, refuse to write conservative (array of pointers) as the
garbage collection type for any variable in the data/bss GC program.
In the linker, attach the Go type to an already-read C declaration
during dedup. This gives us Go types for C globals for free as long
as the cmd/dist-generated Go code contains the declaration.
(Most runtime C declarations have a corresponding Go declaration.
Both are bss declarations and so the linker dedups them.)
In cmd/dist, add a few more C files to the auto-Go-declaration list
in order to get Go type information for the C declarations into the linker.
In C compiler, mark all non-pointer-containing global declarations
and all string data as NOPTR. This allows them to exist in C files
without any corresponding Go declaration. Count C function pointers
as "non-pointer-containing", since we have no heap-allocated C functions.
In runtime, add NOPTR to the remaining pointer-containing declarations,
none of which refer to Go heap objects.
In runtime, also move os.Args and syscall.envs data into runtime-owned
variables. Otherwise, in programs that do not import os or syscall, the
runtime variables named os.Args and syscall.envs will be missing type
information.
I believe that this CL eliminates the final source of conservative GC scanning
in non-SWIG Go programs, and therefore...
Fixes#909.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/149770043
The file was created just to have something to check in
to create the new branch. No longer needed.
LGTM=rlh
R=rlh
CC=golang-codereviews
https://golang.org/cl/140670043
Those C files would have been compiled with 6c.
It's close to impossible to use C correctly anymore,
and the C compilers are going away eventually.
Make them unavailable now.
go1.4.txt change in CL 145890046
LGTM=iant
R=iant
CC=golang-codereviews, r
https://golang.org/cl/149720043
Normally, the caller to runtime.entersyscall() must not return before
calling runtime.exitsyscall(), lest g->syscallsp become a dangling
pointer. runtime.cgocallbackg() violates this constraint. To work around
this, save g->syscallsp and g->syscallpc around cgo->Go callbacks, then
restore them after calling runtime.entersyscall(), which restores the
syscall stack frame pointer saved by cgocall. This allows the GC to
correctly trace a goroutine that is currently returning from a
Go->cgo->Go chain.
This also adds a check to proc.c that panics if g->syscallsp is clearly
invalid. It is not 100% foolproof, as it will not catch a case where the
stack was popped then pushed back beyond g->syscallsp, but it does catch
the present cgo issue and makes existing tests fail without the bugfix.
Fixes#7978.
LGTM=dvyukov, rsc
R=golang-codereviews, dvyukov, minux, bradfitz, iant, gobot, rsc
CC=golang-codereviews, rsc
https://golang.org/cl/131910043
There were at least two bugs:
1) It would overwrite a non-archive.
2) It would truncate a non-archive and then fail.
In general the file handling was too clever to be correct.
Make it more straightforward, doing the creation
separately from archive management.
Fixes#8369.
LGTM=adg, iant
R=golang-codereviews, adg, iant
CC=golang-codereviews
https://golang.org/cl/147010046
Was just a missing case (literally) in the type checker.
Fixes#8473.
LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/142460043
Previously, signed and unsigned integers could not be compared, but
this has problems with things like comparing 'x' with a byte in a string.
Since signed and unsigned integers have a well-defined ordering,
even though their types are different, and since we already allow
comparison regardless of the size of the integers, why not allow it
regardless of the sign?
Integers only, a fine place to draw the line.
Fixes#7489.
LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/149780043
Saw this on a test:
runtime: bad pointer in frame runtime_test.testSetPanicOnFault at 0xc20801c6b0: 0xfff
fatal error: bad pointer!
runtime stack:
...
copystack(0xc2081bf7a0, 0x1000)
/root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/stack.c:621 +0x173 fp=0xfffffd7ffd5ffee0 sp=0xfffffd7ffd5ffe20
runtime.newstack()
/root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/stack.c:774 +0x552 fp=0xfffffd7ffd5fff90 sp=0xfffffd7ffd5ffee0
runtime.morestack()
/root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/asm_amd64.s:324 +0x90 fp=0xfffffd7ffd5fff98 sp=0xfffffd7ffd5fff90
goroutine 163354 [stack growth]:
...
runtime.convT2E(0x587000, 0xc20807bea8, 0x0, 0x0)
/root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/iface.go:141 +0xd2 fp=0xc20801c678 sp=0xc20801c640
runtime_test.testSetPanicOnFault(0xc20822c510, 0xfff, 0xc20801c748)
/root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/runtime_test.go:211 +0xc6 fp=0xc20801c718 sp=0xc20801c678
...
This test is testing bad pointers. It loads the bad pointer into a pointer variable,
but before it gets a chance to dereference it, calls convT2E. That call causes a stack copy,
which exposes that live but bad pointer variable.
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews
https://golang.org/cl/146880043
When running defers, we must check whether the defer
has already been marked as started so we don't run it twice.
Fixes#8774.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/142280044
The proposed text in the last CL had a comma that was missing from the submitted spec.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/150720043
Pure renaming. This will make an upcoming CL have smaller diffs.
LGTM=dvyukov, iant
R=iant, dvyukov
CC=golang-codereviews
https://golang.org/cl/142280043
CL 144940043 renamed it from Sched to SchedType
to avoid a lowercasing conflict in the Go code with
the variable named sched.
We've been using just T resolve those conflicts, not Type.
The FooType pattern is already taken for the kind-specific
variants of the runtime Type structure: ChanType, MapType,
and so on. SchedType isn't a Type.
LGTM=bradfitz, khr
R=khr, bradfitz
CC=golang-codereviews
https://golang.org/cl/145180043
Update #8690
If liblink determines that the host doesn't support TLS it replaces the MRC call with a BL runtime.tls_read_fallback. The problem is save_g doesn't expect anyone to make any BL calls and hasn't setup its own link register properly so when runtime.tls_read_fallback returns the LR points to save_g, not save_g's caller so the RET at the end of the function turns into an infinite loop.
This fix is only a proof of concept, I think the real fix should go into liblink as its MRC substitution is not as transparent as expected.
LGTM=rsc
R=rsc, minux
CC=golang-codereviews
https://golang.org/cl/143050043
We can't assume all those addresses are unmapped.
But at least one should be.
What we're really testing is that the program doesn't crash.
Fixes#8542.
LGTM=iant
R=golang-codereviews, iant, minux
CC=golang-codereviews
https://golang.org/cl/144120043
We mark DBG_PRINTEXCEPTION_C messages in VEH handler
as handled, thus preventing debugger from seeing them.
I don't see reason for doing that. The comment warns
of crashes, but I added test and don't see any crashes.
This is also simplify VEH handler before making
changes to fix issue 8006.
Update #8006
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/146800043
This is to simplify VEH handler before making
changes to fix issue 8006.
Update #8006
LGTM=adg, rsc
R=golang-codereviews, adg, rsc
CC=golang-codereviews
https://golang.org/cl/138630043
Same fix as for SysUnused.
Fixes#8038.
LGTM=iant, alex.brainman
R=golang-codereviews, iant, alex.brainman
CC=golang-codereviews
https://golang.org/cl/147820043
The current Windows build failure happens because by
default runtime frames are excluded from stack traces.
Apparently the Windows breakpoint path dies with an
ordinary panic, while the Unix path dies with a throw.
Breakpoint is a strange function and I don't mind that it's
a little different on the two operating systems.
The panic squelches runtime frames but the throw shows them,
because throw is considered something that shouldn't have
happened at all, so as much detail as possible is wanted.
The runtime exclusion is meant to prevents printing too much noise
about internal runtime details. But exported functions are
not internal details, so show exported functions.
If the program dies because you called runtime.Breakpoint,
it's okay to see that frame.
This makes the Breakpoint test show Breakpoint in the
stack trace no matter how it is handled.
Should fix Windows build.
Tested on Unix by changing Breakpoint to fault instead
of doing a breakpoint.
TBR=brainman
CC=golang-codereviews
https://golang.org/cl/143300043
This fixes a couple of problems that occur when the linker
removes its temporary directory on Windows. The linker only
creates and removes a temporary directory when doing external
linking. Windows does not yet support external linking.
Therefore, these problems are only seen when using a
cross-compiler hosted on Windows.
In lib9, FindFirstFileW returns just the file name, not the
full path name. Don't assume that we will find a slash.
Changed the code to work either way just in case.
In ld, Windows requires that files be closed before they are
removed, so close the output file before we might try to
remove it.
Fixes#8723.
LGTM=alex.brainman
R=golang-codereviews, alex.brainman
CC=golang-codereviews
https://golang.org/cl/141690043
It's just fundamentally incompatible with
Windows' pickiness about removing things
that are in use.
TBR=brainman
CC=golang-codereviews
https://golang.org/cl/142270043
Since CL 130990043, the GOTRACEBACK variable is
only used when the GODEBUG variable is set.
This change restores the original behavior.
LGTM=rsc
R=golang-codereviews, aram, gobot, r, rsc
CC=golang-codereviews
https://golang.org/cl/132520043
In Go 1.3 the runtime called panicstring to report errors like
divide by zero or memory faults. Now we call panic (gopanic)
with pre-allocated error values. That new path is missing the
checking that panicstring did, so add it there.
The only call to panicstring left is in cnew, which is problematic
because if it fails, probably the heap is corrupt. In that case,
calling panicstring creates a new errorCString (no allocation there),
but then panic tries to print it, invoking errorCString.Error, which
does a string concatenation (allocating), which then dies.
Replace that one panicstring with a throw: cnew is for allocating
runtime data structures and should never ask for an inappropriate
amount of memory.
With panicstring gone, delete newErrorCString, errorCString.
While we're here, delete newErrorString, not called by anyone.
(It can't be: that would be C code calling Go code that might
block or grow the stack.)
Found while debugging a malloc corruption.
This resulted in 'panic during panic' instead of a more useful message.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/138290045
It fails about 25% of the time on OS X.
I don't know what it's trying to do.
Created issue 8764 to correct this, but for now disable.
LGTM=bradfitz, mikioh.mikioh
R=bradfitz, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/144070044
Converting an integer to an interface{} allocates as of CL 130240043.
Fixes#8617.
LGTM=r
R=r
CC=golang-codereviews, khr
https://golang.org/cl/141700043
It is left from the time when Value was implemented in assembly.
Now it is implemented in Go and race detector understands Go.
In particular the atomic operations must provide
all necessary synchronization.
LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews, khr, rsc
https://golang.org/cl/145880043
We could probably free the G structures as well, but
for the allg list. Leaving that for another day.
Fixes#8287
LGTM=rsc
R=golang-codereviews, dvyukov, khr, rsc
CC=golang-codereviews
https://golang.org/cl/145010043
The logic here is copied from mgc0.c's scanframe.
Mostly it is messages although the minsize code is new
(and I believe necessary).
I am hoping to get more information about the current
arm build failures (or, if it's the minsize thing, fix them).
TBR=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/143180043
It will be 8K on windows because it needs 4K for the OS.
Similarly, plan9 will be 4K.
On linux/amd64, reduces size of 100,000 goroutines
from ~819MB to ~245MB.
Update #7514
LGTM=dvyukov
R=golang-codereviews, dvyukov, khr, aram
CC=golang-codereviews
https://golang.org/cl/145790043
A Value provides an atomic load and store of a consistently typed value.
It's intended to be used with copy-on-write idiom (see the example).
Performance:
BenchmarkValueRead 50000000 21.7 ns/op
BenchmarkValueRead-2 200000000 8.63 ns/op
BenchmarkValueRead-4 300000000 4.33 ns/op
TBR=rsc
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/136710045
The liblink code to insert the FUNCDATA for a stack map
from the Go prototype was not correct for ARM
(different data structure layout).
Also, sync/atomic was missing some Go prototypes
for ARM-specific functions.
TBR=r
CC=golang-codereviews
https://golang.org/cl/143160045
semacquire might need to park the currently running G. It can
only park if called from the G stack (because it has no way of
saving the M stack state). So all calls to semacquire must come
from the G stack.
The three violators are GOMAXPROCS, ReadMemStats, and WriteHeapDump.
This change moves the semacquire call earlier, out of their C code
and into their Go code.
This seldom caused bugs because semacquire seldom actually had
to park the caller. But it did happen intermittently.
Fixes#8749
LGTM=dvyukov
R=golang-codereviews, dvyukov, bradfitz
CC=golang-codereviews
https://golang.org/cl/144940043
If this needs to be turned back off, it should be done
just before the '// in finalizer' comment, not at the top
of the function.
GC is more precise now than it was (the only imprecise
stuff left is some global variables), so maybe the finalizer
test will work now on 32-bit systems.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/144030043
Like most of the Type methods, the definition of Comparable
is what the Go spec says it is.
Fixes#7911.
LGTM=gri
R=gri, r
CC=golang-codereviews
https://golang.org/cl/144020043
If there is a leading ·, assume there is a Go prototype and
attach the Go prototype information to the function.
If the function is not called from Go and does not need a
Go prototype, it can be made file-local instead (using name<>(SB)).
This fixes the current BSD build failures, by giving functions like
sync/atomic.StoreUint32 argument stack map information.
Fixes#8753.
LGTM=khr, iant
R=golang-codereviews, iant, khr, bradfitz
CC=golang-codereviews, r, rlh
https://golang.org/cl/142150043
This is a corner case, and one that was even tested, but this
CL changes the behavior to say that f is "complete" even if it panics.
But don't think of it that way, think of it as sync.Once runs
the function only the first time it is called, rather than
repeatedly until a run of the function completes.
Fixes#8118.
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews
https://golang.org/cl/137350043
We believe TestSelfConnect can accidentally connect to
something else listening on or dialing from that port.
Fixes#8680.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews, rlh
https://golang.org/cl/136700043
There's no point in continuing. We will only get confused.
6g already makes this fatal.
LGTM=dave, minux, iant
R=iant, dave, minux
CC=golang-codereviews
https://golang.org/cl/140660043
This branch is for Rick Hudson's work on concurrent collection,
targeted to land at the beginning of the 1.5 cycle.
LGTM=rlh
R=rlh
CC=golang-codereviews
https://golang.org/cl/138510043
Along with CLs 139610043 and 141490043,
this removes all conservative scanning during
garbage collection, except _cgo_allocate,
which is SWIG-only.
LGTM=rlh, khr
R=golang-codereviews, dvyukov, rlh, khr
CC=golang-codereviews, iant
https://golang.org/cl/144860043
Now it's two allocations. I don't see much downside to that,
since the two pieces were in different cache lines anyway.
Rename 'conservative' to 'cgo_conservative_type' and make
clear that _cgo_allocate is the only allowed user.
This depends on CL 141490043, which removes the other
use of conservative (in defer).
LGTM=dvyukov, iant
R=khr, dvyukov, iant
CC=golang-codereviews, rlh
https://golang.org/cl/139610043
This makes the GC and the stack copying agree about how
to interpret the defer structures. Previously, only the stack
copying treated them precisely.
This removes an untyped memory allocation and fixes
at least three copystack bugs.
To make sure the GC can find the deferred argument
frame until it has been copied, keep a Defer on the defer list
during its execution.
In addition to making it possible to remove the untyped
memory allocation, keeping the Defer on the list fixes
two races between copystack and execution of defers
(in both gopanic and Goexit). The problem is that once
the defer has been taken off the list, a stack copy that
happens before the deferred arguments have been copied
back to the stack will not update the arguments correctly.
The new tests TestDeferPtrsPanic and TestDeferPtrsGoexit
(variations on the existing TestDeferPtrs) pass now but
failed before this CL.
In addition to those fixes, keeping the Defer on the list
helps correct a dangling pointer error during copystack.
The traceback routines walk the Defer chain to provide
information about where a panic may resume execution.
When the executing Defer was not on the Defer chain
but instead linked from the Panic chain, the traceback
had to walk the Panic chain too. But Panic structs are
on the stack and being updated by copystack.
Traceback's use of the Panic chain while copystack is
updating those structs means that it can follow an
updated pointer and find itself reading from the new stack.
The new stack is usually all zeros, so it sees an incorrect
early end to the chain. The new TestPanicUseStack makes
this happen at tip and dies when adjustdefers finds an
unexpected argp. The new StackCopyPoison mode
causes an earlier bad dereference instead.
By keeping the Defer on the list, traceback can avoid
walking the Panic chain at all, making it okay for copystack
to update the Panics.
We'd have the same problem for any Defers on the stack.
There was only one: gopanic's dabort. Since we are not
taking the executing Defer off the chain, we can use it
to do what dabort was doing, and then there are no
Defers on the stack ever, so it is okay for traceback to use
the Defer chain even while copystack is executing:
copystack cannot modify the Defer chain.
LGTM=khr
R=khr
CC=dvyukov, golang-codereviews, iant, rlh
https://golang.org/cl/141490043
The C header files are the single point of truth:
every C enum constant Foo is available to Go as _Foo.
Remove or redirect duplicate Go declarations so they
cannot be out of sync.
Eventually we will need to put constants in Go, but for now having
them be out of sync with C is too risky. These predate the build
support for auto-generating Go constants from the C definitions.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/141510043
iterdelete's run time varies; occasionally we get unlucky. To reduce spurious failures, average away some of the variation.
On my machine, 8 of 5000 runs (0.15%) failed before this CL. After this CL, there were no failures after 35,000 runs.
I confirmed that this adjusted test still fails before CL 141270043.
LGTM=khr
R=khr
CC=bradfitz, golang-codereviews
https://golang.org/cl/140610043
During anylit run, nodes such as SLICEARR(statictmp, [:])
may be generated and are expected to be found unchanged by
gen_as_init.
In some walks (in particular walkselect), the statement
may be walked again and lowered to its usual form, leading to a
crash.
Fixes#8017.
Fixes#8024.
Fixes#8058.
LGTM=rsc
R=golang-codereviews, dvyukov, gobot, rsc
CC=golang-codereviews
https://golang.org/cl/112080043
Previously it might happen before calling dowidth and
result in a compiler crash.
Fixes#8060.
LGTM=dvyukov, rsc
R=golang-codereviews, dvyukov, gobot, rsc
CC=golang-codereviews
https://golang.org/cl/110980044
I have made mistake while converting it to Go (CL 132820043).
Added test as penance for my sin.
LGTM=rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/136560043
This file was already assigned to another CL
so it didn't make it into the build fix CL. Sigh.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/144850043
This is necessary because syscall.Syscall blocks, and the
garbage collector needs to be able to scan that frame while
it is blocked, and C frames have no garbage collection
information.
Windows builders are broken now due to this problem:
http://build.golang.org/log/152ca9a4be6783d3a8bf6e2f5b9fc265089728b6
LGTM=alex.brainman
R=alex.brainman
CC=golang-codereviews
https://golang.org/cl/144830043
The merged traceback was wrong for LR machines,
because traceback didn't pass lr to gentraceback.
Now that we have a test looking at traceback output
for a trap (the test of runtime.Breakpoint),
we caught this.
While we're here, fix a 'set and not used' warning.
Fixes arm build.
TBR=r
R=r
CC=golang-codereviews
https://golang.org/cl/143040043
It doesn't.
Fixes 386 build.
While we're here, mark runtime.asmcgocall as GO_ARGS,
so that it will work with stack copying. I don't think anything
that uses it can lead to a stack copy, but better safe than sorry.
Certainly the runtime.asmcgocall_errno variant needs
(and already has) GO_ARGS.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/138400043
The argsize PCDATA was specifying the number of
bytes passed to a function call, so that if the function
did not specify its argument count, the garbage collector
could use the call site information to scan those bytes
conservatively. We don't do that anymore, so stop
generating the information.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/139530043
The goal here is to commit fully to having precise information
about stack frames. If we need information we don't have,
crash instead of assuming we should scan conservatively.
Since the stack copying assumes fully precise information,
any crashes during garbage collection that are introduced by
this CL are crashes that could have happened during stack
copying instead. Those are harder to find because stacks are
copied much less often than the garbage collector is invoked.
In service of that goal, remove ARGSIZE macros from
asm_*.s, change switchtoM to have no arguments
(it doesn't have any live arguments), and add
args and locals information to some frames that
can call back into Go.
LGTM=khr
R=khr, rlh
CC=golang-codereviews
https://golang.org/cl/137540043
Dmitriy changed all the execution to interpret the BitVector
as an array of bytes. Update the declaration and generation
of the bitmaps to match, to avoid problems on big-endian
machines.
LGTM=khr
R=khr
CC=dvyukov, golang-codereviews
https://golang.org/cl/140570044
makeFuncStub and methodValueStub are used by reflect as
generic function implementations. Each call might have
different arguments. Extract those arguments from the
closure data instead of assuming it is the same each time.
Because the argument map is now being extracted from the
function itself, we don't need the special cases in reflect.Call
anymore, so delete those.
Fixes an occasional crash seen when stack copying does
not update makeFuncStub's arguments correctly.
Will also help make it safe to require stack maps in the
garbage collector.
Derived from CL 142000044 by khr.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/143890044
The pid field in the Tos structure is a 32-bit value.
Loading a 64-bit word also brings in the next field
which is used for the profiling clock.
LGTM=0intro, aram
R=rsc, 0intro, aram
CC=golang-codereviews, mischief
https://golang.org/cl/139560044
Before, Syscall and friends were having their arguments
treated conservatively. Now they will use the Go prototype,
which will mean the arguments are not considered pointers
at all.
This is safe because of CL 139360044.
The fact that all these non-Solaris systems were using
conservative scanning of the Syscall arguments is why
the failure that prompted CL 139360044 was only
observed on Solaris, which does something completely different.
If we'd done this earlier, we'd have seen the Solaris
failure in more places.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/144730043
The goal here is to allow assembly functions to appear in the middle
of a Go stack (having called other code) and still record enough information
about their pointers so that stack copying and garbage collection can handle
them precisely. Today, these frames are handled only conservatively.
If you write
func myfunc(x *float64) (y *int)
(with no body, an 'extern' declaration), then the Go compiler now emits
a liveness bitmap for use from the assembly definition of myfunc.
The bitmap symbol is myfunc.args_stackmap and it contains two bitmaps.
The first bitmap, in effect at function entry, marks all inputs as live.
The second bitmap, not in effect at function entry, marks the outputs
live as well.
In funcdata.h, define new assembly macros:
GO_ARGS opts in to using the Go compiler-generated liveness bitmap
for the current function.
GO_RESULTS_INITIALIZED indicates that the results have been initialized
and need to be kept live for the remainder of the function; it causes a
switch to the second generated bitmap for the assembly code that follows.
NO_LOCAL_POINTERS indicates that there are no pointers in the
local variables being stored in the function's stack frame.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/137520043
Tests will come in a separate CL after the funcdata stuff is resolved.
Update #8696
LGTM=iant, rsc
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/138330045
Making the child's process group the foreground process group and
placing the child in a specific process group involves co-ordination
between the parent and child that must be done post-fork but pre-exec.
LGTM=iant
R=golang-codereviews, gobot, iant, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/131750044
Just go ahead and do it, if something is wrong we'll throw.
Also rip out cc-generated arg ptr maps, they are useless now.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/133690045
Replacing gosched with Gosched broke some builds because
some of the call sites are at times when the stack cannot be grown.
TBR=khr
CC=golang-codereviews
https://golang.org/cl/142000043
Details: Until now, when we saw a key:value pair that fit onto
a single line, we assumed that it should be formatted with a
vtab after the ':' for alignment of its value. This leads to
odd behavior if there are more than one such pair on a line.
This CL changes the behavior such that alignment is only used
for the first pair on a line. This preserves existing behavior
(in the std lib we have composite literals where the last line
contains multiple entries and the first entry's value is aligned
with the values on previous lines), and resolves this issue.
No impact on formatting of std lib, go.tools, go.exp, go.net.
Fixes#8685.
LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/139430043
A write *p = x that needs a write barrier (not all do)
now turns into runtime.writebarrierptr(p, x)
or one of the other variants.
The write barrier implementations are trivial.
The goal here is to emit the calls in the correct places
and to incur the cost of those function calls in the Go 1.4 cycle.
Performance on the Go 1 benchmark suite below.
Remember, the goal is to slow things down (and be correct).
We will look into optimizations in separate CLs, as part of
the process of comparing Go 1.3 against tip in order to make
sure Go 1.4 runs at least as fast as Go 1.3.
benchmark old ns/op new ns/op delta
BenchmarkBinaryTree17 3118336716 3452876110 +10.73%
BenchmarkFannkuch11 3184497677 3211552284 +0.85%
BenchmarkFmtFprintfEmpty 89.9 107 +19.02%
BenchmarkFmtFprintfString 236 287 +21.61%
BenchmarkFmtFprintfInt 246 278 +13.01%
BenchmarkFmtFprintfIntInt 395 458 +15.95%
BenchmarkFmtFprintfPrefixedInt 343 378 +10.20%
BenchmarkFmtFprintfFloat 477 525 +10.06%
BenchmarkFmtManyArgs 1446 1707 +18.05%
BenchmarkGobDecode 14398047 14685958 +2.00%
BenchmarkGobEncode 12557718 12947104 +3.10%
BenchmarkGzip 453462345 472413285 +4.18%
BenchmarkGunzip 114226016 115127398 +0.79%
BenchmarkHTTPClientServer 114689 112122 -2.24%
BenchmarkJSONEncode 24914536 26135942 +4.90%
BenchmarkJSONDecode 86832877 103620289 +19.33%
BenchmarkMandelbrot200 4833452 4898780 +1.35%
BenchmarkGoParse 4317976 4835474 +11.98%
BenchmarkRegexpMatchEasy0_32 150 166 +10.67%
BenchmarkRegexpMatchEasy0_1K 393 402 +2.29%
BenchmarkRegexpMatchEasy1_32 125 142 +13.60%
BenchmarkRegexpMatchEasy1_1K 1010 1236 +22.38%
BenchmarkRegexpMatchMedium_32 232 301 +29.74%
BenchmarkRegexpMatchMedium_1K 76963 102721 +33.47%
BenchmarkRegexpMatchHard_32 3833 5463 +42.53%
BenchmarkRegexpMatchHard_1K 119668 161614 +35.05%
BenchmarkRevcomp 763449047 706768534 -7.42%
BenchmarkTemplate 124954724 134834549 +7.91%
BenchmarkTimeParse 517 511 -1.16%
BenchmarkTimeFormat 501 514 +2.59%
benchmark old MB/s new MB/s speedup
BenchmarkGobDecode 53.31 52.26 0.98x
BenchmarkGobEncode 61.12 59.28 0.97x
BenchmarkGzip 42.79 41.08 0.96x
BenchmarkGunzip 169.88 168.55 0.99x
BenchmarkJSONEncode 77.89 74.25 0.95x
BenchmarkJSONDecode 22.35 18.73 0.84x
BenchmarkGoParse 13.41 11.98 0.89x
BenchmarkRegexpMatchEasy0_32 213.30 191.72 0.90x
BenchmarkRegexpMatchEasy0_1K 2603.92 2542.74 0.98x
BenchmarkRegexpMatchEasy1_32 254.00 224.93 0.89x
BenchmarkRegexpMatchEasy1_1K 1013.53 827.98 0.82x
BenchmarkRegexpMatchMedium_32 4.30 3.31 0.77x
BenchmarkRegexpMatchMedium_1K 13.30 9.97 0.75x
BenchmarkRegexpMatchHard_32 8.35 5.86 0.70x
BenchmarkRegexpMatchHard_1K 8.56 6.34 0.74x
BenchmarkRevcomp 332.92 359.62 1.08x
BenchmarkTemplate 15.53 14.39 0.93x
LGTM=rlh
R=rlh
CC=dvyukov, golang-codereviews, iant, khr, r
https://golang.org/cl/136380043
The uses of onM in dopanic/startpanic are okay even from the signal stack.
Fixes#8666.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/134710043
The previous implementation used per-socket TCP keepalive options
wrong. For example, it used another level socket option to control
TCP and it didn't use TCP_KEEPINTVL option when possible.
Fixes#8683.
Fixes#8701.
Update #8679
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/136480043
They will both need write barriers at some point.
But until then, no reason why we shouldn't share.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/141330043
The previous implementation had several subtle issues. It's not
clear if any of these could actually be causing the flakiness
problems on openbsd/386, but fixing them should only help.
1. thrsleep() is implemented internally as unlock, then test *abort
(if abort != nil), then tsleep(). Under the current code, that makes
it theoretically possible that semasleep()/thrsleep() could release
waitsemalock, then a racing semawakeup() could acquire the lock,
increment waitsemacount, and call thrwakeup()/wakeup() before
thrsleep() reaches tsleep(). (In practice, OpenBSD's big kernel lock
seems unlikely to let this actually happen.)
The proper way to avoid this is to pass &waitsemacount as the abort
pointer to thrsleep so thrsleep knows to re-check it before going to
sleep, and to wakeup if it's non-zero. Then we avoid any races.
(I actually suspect openbsd's sema{sleep,wakeup}() could be further
simplified using cas/xadd instead of locks, but I don't want to be
more intrusive than necessary so late in the 1.4 release cycle.)
2. semasleep() takes a relative sleep duration, but thrsleep() needs
an absolute sleep deadline. Instead of recomputing the deadline each
iteration, compute it once up front and use (*Timespec)(nil) to signify
no deadline. Ensures we retry properly if there's a spurious wakeup.
3. Instead of assuming if thrsleep() woke up and waitsemacount wasn't
available that we must have hit the deadline, check that the system
call returned EWOULDBLOCK.
4. Instead of assuming that 64-bit systems are little-endian, compute
timediv() using a temporary int32 nsec and then assign it to tv_nsec.
LGTM=iant
R=jsing, iant
CC=golang-codereviews
https://golang.org/cl/137960043
A race exists between the parent and child processes after a fork.
The child needs to access the new M pointer passed as an argument
but the parent may have already returned and clobbered it.
Previously, we avoided this by saving the necessary data into
registers before the rfork system call but this isn't guaranteed
to work because Plan 9 makes no promises about the register state
after a system call. Only the 386 kernel seems to save them.
For amd64 and arm, this method won't work.
We eliminate the race by allocating stack space for the scheduler
goroutines (g0) in the per-process copy-on-write stack segment and
by only calling rfork on the scheduler stack.
LGTM=aram, 0intro, rsc
R=aram, 0intro, mischief, rsc
CC=golang-codereviews
https://golang.org/cl/110680044
The only thing I can see that is really Plan 9-specific
is that the stack pointer used for signal handling used
to have more mapped memory above it.
Specifically it used to have at most 88 bytes (StackTop),
so change the allocation of a 40-byte frame to a 128-byte frame.
No idea if this will work, but worth a try.
Note that "fix" here means get it back to timing out
instead of crashing.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/142840043
The difference between the old and the new (from earlier) code
is that we set stackguard = stack.lo + StackGuard, while the old
code set stackguard = stack.lo. That 512 bytes appears to be
the difference between the profileloop function running and not running.
We don't know how big the system stack is, but it is likely MUCH bigger than 4k.
Give Go/C 8k.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/140440044
Start the stack a few words below the actual top, so that
if something tries to read goexit's caller PC from the stack,
it won't fault on a bad memory address.
Today, heapdump does that.
Maybe tomorrow, traceback or something else will do that.
Make it not a bug.
TBR=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/136450043
For -mode=atomic, we need to read the counters
using an atomic load to avoid a race. Not worth worrying
about when -mode=atomic is set during generation
of the profile, so we use atomic loads always.
Fixes#8630.
LGTM=rsc
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/141800043
With new interface allocation rules, the old counts were wrong and
so was the commentary.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/142760044
Commit to stack copying for stack growth.
We're carrying around a surprising amount of cruft from older schemes.
I am confident that precise stack scans and stack copying are here to stay.
Delete fallback code for when precise stack info is disabled.
Delete fallback code for when copying stacks is disabled.
Delete fallback code for when StackCopyAlways is disabled.
Delete Stktop chain - there is only one stack segment now.
Delete M.moreargp, M.moreargsize, M.moreframesize, M.cret.
Delete G.writenbuf (unrelated, just dead).
Delete runtime.lessstack, runtime.oldstack.
Delete many amd64 morestack variants.
Delete initialization of morestack frame/arg sizes (shortens split prologue!).
Replace G's stackguard/stackbase/stack0/stacksize/
syscallstack/syscallguard/forkstackguard with simple stack
bounds (lo, hi).
Update liblink, runtime/cgo for adjustments to G.
LGTM=khr
R=khr, bradfitz
CC=golang-codereviews, iant, r
https://golang.org/cl/137410043
I have found better approach, then longer wait.
See CL 134360043 for details.
««« original CL description
runtime/pprof: adjust cpuHogger so that tests pass on windows builders
LGTM=rsc
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/140110043
»»»
LGTM=dave
R=golang-codereviews, dave, dvyukov
CC=golang-codereviews
https://golang.org/cl/133500043
I assumed they were the same when I wrote
cgocallback.go earlier today. Merge them
to eliminate confusion.
I can't tell what gomallocgc did before with
a nil type but without FlagNoScan.
I created a call like that in cgocallback.go
this morning, translating from a C file.
It was supposed to do what the C version did,
namely treat the block conservatively.
Now it will.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/141810043
It already is updating parts of them; we're just getting lucky
retraversing them and not finding much to do.
Change argp to a pointer so that it will be updated too.
Existing tests break if you apply the change to adjustpanics
without also updating the type of argp.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/139380043
It worked at CL 134660043 on the builders,
so I believe it will stick this time.
LGTM=bradfitz
R=khr, bradfitz
CC=golang-codereviews
https://golang.org/cl/141280043
Inside a control clause (if ... {}), composite
literals starting with a type name must be parenthesized.
A composite literal used in the array length expression
of an array composite literal is already parenthesized.
Not a valid program, but syntactically is should
be accepted.
LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/142760043
This should make deferreturn nosplit all the way down,
which should fix the current windows/amd64 failure.
If not, I will change StackCopyAlways back to 0.
TBR=khr
CC=golang-codereviews
https://golang.org/cl/135600043
Let's see how close we are to this being ready.
Will roll back if it breaks any builds in non-trivial ways.
LGTM=r, khr
R=iant, khr, r
CC=golang-codereviews
https://golang.org/cl/138200043
Given:
p := alloc()
fn_taking_ptr(p)
p is NOT recorded as live at the call to fn_taking_ptr:
it's not needed by the code following the call.
p was passed to fn_taking_ptr, and fn_taking_ptr must keep
it alive as long as it needs it.
In practice, fn_taking_ptr will keep its own arguments live
for as long as the function is executing.
But if instead you have:
p := alloc()
i := uintptr(unsafe.Pointer(p))
fn_taking_int(i)
p is STILL NOT recorded as live at the call to fn_taking_int:
it's not needed by the code following the call.
fn_taking_int is responsible for keeping its own arguments
live, but fn_taking_int is written to take an integer, so even
though fn_taking_int does keep its argument live, that argument
does not keep the allocated memory live, because the garbage
collector does not dereference integers.
The shorter form:
p := alloc()
fn_taking_int(uintptr(unsafe.Pointer(p)))
and the even shorter form:
fn_taking_int(uintptr(unsafe.Pointer(alloc())))
are both the same as the 3-line form above.
syscall.Syscall is like fn_taking_int: it is written to take a list
of integers, and yet those integers are sometimes pointers.
If there is no other copy of those pointers being kept live,
the memory they point at may be garbage collected during
the call to syscall.Syscall.
This is happening on Solaris: for whatever reason, the timing
is such that the garbage collector manages to free the string
argument to the open(2) system call before the system call
has been invoked.
Change the system call wrappers to insert explicit references
that will keep the allocations alive in the original frame
(and therefore preserve the memory) until after syscall.Syscall
has returned.
Should fix Solaris flakiness.
This is not a problem for cgo, because cgo wrappers have
correctly typed arguments.
LGTM=iant, khr, aram, rlh
R=iant, khr, bradfitz, aram, rlh
CC=dvyukov, golang-codereviews, r
https://golang.org/cl/139360044
The sighander has been run at the bottom of the
currently executing goroutine stack, but it's in C,
and we don't want C on our ordinary goroutine stacks.
Worse, it does a lot of stuff, and it might need more
stack space. There is scary code in traceback_windows.go
that talks about stack splits during sighandler.
Moving sighandler to g0 will eliminate the possibility
of stack splits and such, and then we can delete
traceback_windows.go entirely. Win win.
On the builder, all.bat passes with GOARCH=amd64
and all.bat gets most of the way with GOARCH=386
except for a DLL-loading test that I think is unrelated.
Fixes windows build.
TBR=brainman, iant
CC=golang-codereviews
https://golang.org/cl/140380043
This CL contains compiler+runtime changes that detect C code
running on Go (not g0, not gsignal) stacks, and it contains
corrections for what it detected.
The detection works by changing the C prologue to use a different
stack guard word in the G than Go prologue does. On the g0 and
gsignal stacks, that stack guard word is set to the usual
stack guard value. But on ordinary Go stacks, that stack
guard word is set to ^0, which will make any stack split
check fail. The C prologue then calls morestackc instead
of morestack, and morestackc aborts the program with
a message about running C code on a Go stack.
This check catches all C code running on the Go stack
except NOSPLIT code. The NOSPLIT code is allowed,
so the check is complete. Since it is a dynamic check,
the code must execute to be caught. But unlike the static
checks we've been using in cmd/ld, the dynamic check
works with function pointers and other indirect calls.
For example it caught sigpanic being pushed onto Go
stacks in the signal handlers.
Fixes#8667.
LGTM=khr, iant
R=golang-codereviews, khr, iant
CC=golang-codereviews, r
https://golang.org/cl/133700043
Fixes warning
# _/home/dfc/go/misc/cgo/test/backdoor
/home/dfc/go/src/cmd/cc/bv.c:43:11: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/136330043
Fixes warning
/home/dfc/go/src/cmd/gc/subr.c:3469:8: runtime error: negation of -9223372036854775808 cannot be represented in type 'int64' (aka 'long'); cast to an unsigned type to negate this value to itself
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/141220043
This CL adjusts code referring to src/pkg to refer to src.
Immediately after submitting this CL, I will submit
a change doing 'hg mv src/pkg/* src'.
That change will be too large to review with Rietveld
but will contain only the 'hg mv'.
This CL will break the build.
The followup 'hg mv' will fix it.
For more about the move, see golang.org/s/go14nopkg.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/134570043
These all used a C implementation that contained 64-bit divide by 1000000000.
On 32-bit systems that ends up in the 64-bit C divide support, which makes
other calls and ends up using a fair amount of stack. We could convert them
to Go but then they'd still end up in software 64-bit divide code. That would
be okay, because Go code can split the stack, but it's still unnecessary.
Write time·now in assembly, just like on all the other systems, and use the
actual hardware support for 64/32 -> 64/32 division. This cuts the software
routines out entirely.
The actual code to do the division is copied and pasted from the sys_darwin_*.s files.
LGTM=alex.brainman
R=golang-codereviews, alex.brainman
CC=aram, golang-codereviews, iant, khr, r
https://golang.org/cl/136300043
Now it's failing on Windows:
panic: httptest: failed to listen on a port: listen tcp 127.0.0.1:0:
listen: An operation on a socket could not be performed because the
system lacked sufficient buffer space or because a queue was full.
Since we can't seem to understand what the test is trying to test,
and because it is causing problems on multiple systems,
delete it.
Fixes#7264.
TBR=bradfitz
CC=brainman, golang-codereviews
https://golang.org/cl/141210043
I am seeing deadlocks waiting on <-inHandler.
It seems to me that there is no guarantee that the
handler actually runs, if the client does
write header
close connection
fast enough. The server might see the EOF on the
connection before it manages to invoke the handler.
This change fixes the deadlock, but it may make
the test not actually test anything. Not sure.
LGTM=bradfitz
R=bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/140970043
This is one of those "how did this ever work?" bugs.
The current build failures are happening because
a fault comes up while executing on m->curg on a
system-created thread using an m obtained from needm,
but TLS is set to m->g0, not m->curg. On fault,
sigtramp starts executing, assumes r10 (g) might be
incorrect, reloads it from TLS, and gets m->g0, not
m->curg. Then sighandler dutifully pushes a call to
sigpanic onto the stack and returns to it.
We're now executing on the m->curg stack but with
g=m->g0. Sigpanic does a stack split check, sees that
the SP is not in range (50% chance depending on relative
ordering of m->g0's and m->curg's stacks), and then
calls morestack. Morestack sees that g=m->g0 and
crashes the program.
The fix is to replace every change of g in asm_arm.s
with a call to a function that both updates g and
saves the updated g to TLS.
Why did it start happening? That's unclear.
Unfortunately there were other bugs in the initial
checkin that mask exactly which of a sequence of
CLs started the behavior where sigpanic would end
up tripping the stack split.
Fixes arm build.
Fixes#8675.
LGTM=iant
R=golang-codereviews, iant
CC=dave, golang-codereviews, khr, minux, r
https://golang.org/cl/135570043
After the three pending CLs listed below, there will be no more .goc files.
134580043 runtime: move stubs.goc code into runtime.c
133670043 runtime: fix windows syscalls for copying stacks
141180043 runtime: eliminate Go -> C -> block paths for Solaris
LGTM=bradfitz
R=golang-codereviews, bradfitz, dave
CC=golang-codereviews, iant, r
https://golang.org/cl/132680043
Syscall and everything it calls must be nosplit:
we cannot split a stack once Syscall has been invoked,
because we don't know which of its arguments are
pointers.
LGTM=khr, r, alex.brainman
R=dvyukov, iant, khr, r, bradfitz, alex.brainman
CC=golang-codereviews
https://golang.org/cl/133670043
Increase NOSPLIT reservation from 192 to 384 bytes.
The problem is that the non-Unix systems (Solaris and Windows)
just can't make system calls in a small amount of space,
and then worse they do things that are complex enough
to warrant calling runtime.throw on failure.
We don't have time to rewrite the code to use less stack.
I'm not happy about this, but it's still a small amount.
The good news is that we're doing this to get to only
using copying stacks for stack growth. Once that is true,
we can drop the default stack size from 8k to 4k, which
should more than make up for the bytes we're losing here.
LGTM=r
R=iant, r, bradfitz, aram.h
CC=golang-codereviews
https://golang.org/cl/140350043
This will keep the go command from trying to build it
when the cmd/ tree is no longer a special case.
Also update doc.go to refer to the correct location.
(It was incorrect even before this CL.)
LGTM=r
R=iant, r
CC=golang-codereviews
https://golang.org/cl/134560043
Now that the calling conventions are the same,
there's no danger to using plain C for these.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=dvyukov, golang-codereviews, iant, khr, r
https://golang.org/cl/134580043
This was supposed to be in CL 135490044
but got lost in a transfer from machine to machine.
TBR=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/135560043
The gp->panicwrap adjustment is just fatally flawed.
Now that there is a Panic.argp field, update that instead.
That can be done on entry only, so that unwinding doesn't
need to worry about undoing anything. The wrappers
emit a few more instructions in the prologue but everything
else in the system gets much simpler.
It also fixes (without trying) a broken test I never checked in.
Fixes#7491.
LGTM=khr
R=khr
CC=dvyukov, golang-codereviews, iant, r
https://golang.org/cl/135490044
testSchedLocal* tests need to malloc now because their
stack frames are too big to fit on the G0 stack.
LGTM=iant
R=golang-codereviews, iant, khr
CC=golang-codereviews
https://golang.org/cl/133660043
newstackcall creates a new stack segment, and we want to
be able to throw away all that code.
LGTM=khr
R=khr, iant
CC=dvyukov, golang-codereviews, r
https://golang.org/cl/139270043
If there is doubt about passing arguments correctly
(as there is in this test), there should be doubt about
getting the results back intact too. Using 0 and 1
(especially 0 for success) makes it easy to get a PASS
accidentally when the return value is not actually
being propagated. Use less common values.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/141110043
We cannot let a real panic start there, because there is C code
on the stack, and worse, there is an assembly frame with a
saved copy of the registers and we have no idea which ones
are pointers.
Instead, detect the nil ptr load/store and return out of the C
and assembly into a stub that will start the call to sigpanic.
Fixes GOARM=5 build.
LGTM=iant
R=golang-codereviews, iant
CC=dave, golang-codereviews, minux, r
https://golang.org/cl/138130043
Minor changes to make logic clearer.
Observed while working on the conversion.
LGTM=iant, dvyukov
R=dvyukov, iant
CC=golang-codereviews
https://golang.org/cl/140250043
created panic1.go just so diffs were available.
After this CL is in, I'd like to move panic.go -> defer.go
and panic1.go -> panic.go.
LGTM=rsc
R=rsc, khr
CC=golang-codereviews
https://golang.org/cl/133530045
sigprof and setcpuprofilerate coordinate the enabling/disabling
of the handler using a Mutex. This has always been a bit dodgy:
setcpuprofilerate must be careful to turn off signals before acquiring
the lock to avoid a deadlock.
Now the lock implementations use onM, and onM isn't okay on the
signal stack. We know how to make it okay, but it's more work than
is probably worth doing.
Since this is super-dodgy anyway, replace the lock with a simple
cas loop. It is only contended if setcpuprofilerate is being called,
and that doesn't happen frequently enough to care about the
raw speed or about using futexes/semaphores.
TBR to fix freebsd/amd64 and dragonfly/amd64 builds.
Happy to make changes in a follow-up CL.
TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/141080044
The general kernel system call interface
takes 6 arguments: R0, R1, R2, R3, R4, R5.
Syscall is for calls that only need 3.
The amd64 and 386 versions zero the extra arg registers,
but the arm version does not.
func utimensat calls Syscall with 3 arguments.
The kernel expects a 4th argument.
That turns out to be whatever is in R3 at the time of the call.
CL 137160043 changed various pieces of code and apparently
changed the value left in R3 at the time of utimensat's Syscall.
This causes the kernel to return EINVAL.
Change linux/arm Syscall to zero R3, R4, R5, so that calls will
behave deterministically, even if they pass too few arguments.
Arguably, utimensat could be fixed too, but the predictable
zeroing is certainly worth doing, and once done utimensat's
use of Syscall is fine.
Fixes arm build.
TBR=bradfitz
CC=golang-codereviews
https://golang.org/cl/141080043
I did this just to clean things up, but it will be important
when we drop the pkg directory later.
LGTM=bradfitz
R=r, bradfitz
CC=golang-codereviews
https://golang.org/cl/132600043
Behavior before this CL:
1. If onM is called on a g0 stack, it just calls the given function.
2. If onM is called on a gsignal stack, it calls badonm.
3. If onM is called on a curg stack, it switches to the g0 stack
and then calls the function.
In cases 1 and 2, if the program then crashes (and badonm always does),
we want to see what called onM, but the traceback stops at onM.
In case 3, the traceback must stop at onM, because the g0
stack we are renting really does stop at onM.
The current code stops the traceback at onM to handle 3,
at the cost of making 1 and 2 crash with incomplete traces.
Change traceback to scan past onM but in case 3 make it look
like on the rented g0 stack, onM was called from mstart.
The traceback already knows that mstart is a top-of-stack function.
Alternate fix at CL 132610043 but I think this one is cleaner.
This CL makes 3 the exception, while that CL makes 1 and 2 the exception.
Submitting TBR to try to get better stack traces out of the
freebsd/amd64 builder, but happy to make changes in a
followup CL.
TBR=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/133620043
The old change worked fine in my client, but my client
must not have been in a completely clean state.
TBR=r
CC=golang-codereviews
https://golang.org/cl/138100043
1) cmd/dist was copying textflag.h to the build include directory,
but only after compiling package runtime. So other packages could
use it, just not runtime. Copy earlier, so that runtime can use it too.
2) We decided for android that anything marked linux is also included
in the build. The generated linux-specific files in cmd/dist must therefore
have explicit +build !android tags, or else you can't have simultaneous
linux/arm and android/arm builds in a single client. The tag was already
there for at least one file, but it was missing from many others.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/134500043
sysAlloc is the only mem function called from Go.
LGTM=iant, khr
R=golang-codereviews, khr, 0intro, iant
CC=dvyukov, golang-codereviews, r
https://golang.org/cl/139210043
Mostly NOSPLIT additions.
Had to rewrite atomic_arm.c in Go because it calls lock,
and lock is too complex.
With this CL, I find no Go -> C calls that can split the stack
on any system except Solaris and Windows.
Solaris and Windows need more work and will be done separately.
LGTM=iant, dave
R=golang-codereviews, bradfitz, iant, dave
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/137160043
The -nocgo builder failed because it has cgo disabled
as well as no USER environment variable:
http://build.golang.org/log/2250abb82f5022b72a12997b8ff89fcdeff094c9
# Checking API compatibility.
Error getting current user: user: Current not implemented on linux/amd64
exit status 1
Don't require the environment variable here.
LGTM=minux
R=dave, adg, minux
CC=golang-codereviews
https://golang.org/cl/140290043
Convert no-op race functions.
Everything else is tiny and gets NOSPLITs.
After this, all that is left on darwin is sysAlloc, panic, and gothrow (all pending).
There may be system-specific calls in other builds.
LGTM=iant
R=golang-codereviews, iant
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/140240044
When this code was written, there was no way for Go to
reuse the C function and enum values. Now there is.
LGTM=bradfitz
R=rlh, bradfitz
CC=dvyukov, golang-codereviews, iant, khr, r
https://golang.org/cl/139150045
The original conversion in CL 132090043 cut up
the function in an attempt to avoid converting most
of the code to Go. This contorts the control flow.
While debugging the onM signal stack bug,
I reconverted sigqueue.goc in its entirety.
This restores the original control flow, which is
much easier to understand.
The current conversion is correct, it's just complex
and will be hard to maintain. The new one is as
readable as the original code.
I uploaded sigqueue.goc as the initial copy of
sigqueue.go in the CL, so if you view the diffs
of sigqueue.go comparing against patch set 2 [sic]
it will show the actual starting point.
For example:
https://golang.org/cl/136160043/diff2/20001:60001/src/pkg/runtime/sigqueue.go
LGTM=dvyukov, iant
R=golang-codereviews, dvyukov, iant
CC=golang-codereviews, khr, r
https://golang.org/cl/136160043
The common code is converted, epoll and kqueue are converted.
Windows and solaris are still C.
LGTM=rsc
R=golang-codereviews, rsc, dave
CC=golang-codereviews, iant, khr, rsc
https://golang.org/cl/132910043
I had this right in one of my clients, but apparently not the one I submitted from.
Fixes 386 builds.
TBR=dfc
CC=golang-codereviews
https://golang.org/cl/138000045
The arm5 build breakage at CL 139110043 was caused by
calling funcPC on a lessstack defined as a struct{}.
That symbol ended up with a non-4-aligned address,
which caused the memory fault that broke the builders.
The definition of lessstack was fixed in CL 140880043.
Tracking that down suggested that it would be worth
looking for the same bug elsewhere in the directory.
This is the only one I found.
LGTM=bradfitz
R=golang-codereviews, dave, bradfitz
CC=dvyukov, golang-codereviews, iant, khr, r
https://golang.org/cl/134410043
Some things get converted.
Other things (too complex or too many C deps) get onM calls.
Other things (too simple) get #pragma textflag NOSPLIT.
After this CL, the offending function list is basically:
- panic.c
- netpoll.goc
- mem*.c
- race stuff
- readgstatus
- entersyscall/exitsyscall
LGTM=r, iant
R=golang-codereviews, r, iant
CC=dvyukov, golang-codereviews, khr
https://golang.org/cl/140930043
The implementation and use patterns of onM assume
that they run on either the m->curg or m->g0 stack.
Calling onM from m->gsignal has two problems:
(1) When not on g0, onM switches to g0 and then "back" to curg.
If we didn't start at curg, bad things happen.
(2) The use of scalararg/ptrarg to pass C arguments and results
assumes that there is only one onM call at a time.
If a gsignal starts running, it may have interrupted the
setup/teardown of the args for an onM on the curg or g0 stack.
Using scalararg/ptrarg itself would smash those.
We can fix (1) by remembering what g was running before the switch.
We can fix (2) by requiring that uses of onM that might happen
on a signal handling stack must save the old scalararg/ptrarg
and restore them after the call, instead of zeroing them.
The only sane way to do this is to introduce a separate
onM_signalsafe that omits the signal check, and then if you
see a call to onM_signalsafe you know the surrounding code
must preserve the old scalararg/ptrarg values.
(The implementation would be that onM_signalsafe just calls
fn if on the signal stack or else jumps to onM. It's not necessary
to have two whole copies of the function.)
(2) is not a problem if the caller and callee are both Go and
a closure is used instead of the scalararg/ptrarg slots.
For now, I think we can avoid calling onM from code executing
on gsignal stacks, so just reject it.
In the long term, (2) goes away (as do the scalararg/ptrarg slots)
once everything is in Go, and at that point fixing (1) would be
trivial and maybe worth doing just for regularity.
LGTM=iant
R=golang-codereviews, iant
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/135400043
Instead of making asmcgocall call asmcgocall_errno,
make both load args into registers and call a shared
assembly function.
On amd64, this costs 1 word in the asmcgocall_errno path
but saves 3 words in the asmcgocall path, and the latter
is what happens on critical nosplit paths on Windows.
On arm, this fixes build failures: asmcgocall was writing
the arguments for asmcgocall_errno into the wrong
place on the stack. Passing them in registers avoids the
decision entirely.
On 386, this isn't really needed, since the nosplit paths
have twice as many words to work with, but do it for consistency.
Update #8635
Fixes arm build (except GOARM=5).
TBR=iant
CC=golang-codereviews
https://golang.org/cl/134390043
I really hoped we could avoid this nonsense, but it appears not.
Should fix windows/amd64 build breakage.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/137120043
This CL fixes a bug introduced by CL 128820043 which is that
builtin dns stub resolver doesn't work well with literal IPv6
address namesever entries in /etc/resolv.conf.
Also simplifies resolv.conf parser and adds more test cases.
LGTM=iant
R=golang-codereviews, bradfitz, iant
CC=golang-codereviews
https://golang.org/cl/140040043
The discriminator in the execution engine was stupid.
Add a test to the parse package too. The problem wasn't there
but the particular case ('e' in a hex integer) was not covered.
Fixes#8622.
LGTM=ruiu
R=golang-codereviews, ruiu
CC=golang-codereviews
https://golang.org/cl/133530043
It is fundamentally unsafe to grow the stack once someone
has made a call to syscall.Syscall. That function takes 6 uintptr
arguments, but depending on the call some are pointers.
In fact, some might be pointers to stack values, and we don't know which.
That makes it impossible to copy the stack somewhere else.
Since we want to delete all the stack splitting code, relying only
on stack copying, make sure that Syscall never needs to split the stack.
The only thing Syscall does is:
call entersyscall
make the system call
call exitsyscall
As long as we make sure that entersyscall and exitsyscall
can live in the nosplit region, they won't ask for more stack.
Do this by making entersyscall and exitsyscall set up the
stack guard so that any call to a function with a split check
will cause a crash. Then move non-essential slow-path
work onto the m stack using onM and mark the rest of the
work nosplit. The linker will verify that the chain of nosplits
fits in the total nosplit budget.
LGTM=iant
R=golang-codereviews, iant
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/140950043
Because symtab.c was partially converted before,
the diffs are not terribly useful.
The earlier conversion was trying to refactor or
clean up the code in addition to doing the translation.
It also made a mistake by redefining Func to be something
users could overwrite.
I undid those changes, making symtab.go a more
literal line-for-line translation of symtab.c instead.
LGTM=josharian
R=golang-codereviews, dave, bradfitz, josharian
CC=golang-codereviews, iant, khr, r
https://golang.org/cl/140880043
We often saw GC pauses of 0 ns, not just on Windows.
Google Compute Engine timer granularity might suck
too.
LGTM=rsc
R=rsc, dvyukov
CC=golang-codereviews
https://golang.org/cl/140910043
The race was in the old C code.
The new Go code does not have the race
and does not need the check.
LGTM=bradfitz, dvyukov
R=golang-codereviews, bradfitz, dvyukov
CC=golang-codereviews, rlh
https://golang.org/cl/140180043
Ignore memory access on g0/gsignal.
See the issue for context and explanation.
Fixes#8627.
LGTM=khr
R=golang-codereviews, mdempsky, khr
CC=golang-codereviews, rsc
https://golang.org/cl/137070043
Code to bring goroutines to a gc safepoint one at a time,
do some work such as scanning, and restart the
goroutine, and then move on to the next goroutine.
Currently this code does not do much useful work
but this infrastructure will be critical to future
concurrent GC work.
Fixed comments reviewers.
LGTM=rsc
R=golang-codereviews, rsc, dvyukov
CC=golang-codereviews
https://golang.org/cl/131580043
This gives them correct types in Go and also makes it
possible to use them to run Go code on an m stack.
LGTM=iant
R=golang-codereviews, dave, iant
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/137970044
They were in proc.c mainly because there was no portable
traceback source file. As part of converting them to Go,
move to traceback.go.
In order to get access to the PC of _rt0_go,
rename to runtime.rt0_go.
LGTM=r
R=golang-codereviews, r
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/139110043
If system is busy burning cpu, it takes long time (about 300ms on
windows builders) to adjust prof thread priority. Once adjusted, prof
thread runs ahead of everyone else, but due to initial slowness, it
does not capture prof snapshots until start-up period is completed.
Change prof thread priority sooner, so it can start captures straight
away.
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews
https://golang.org/cl/134360043
While we are here, give the gc helper a real function name
that will appear in stack traces.
LGTM=rlh
R=rlh
CC=dvyukov, golang-codereviews
https://golang.org/cl/133470043
C and Go calling conventions are now compatible, so we
don't need two versions of this function.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/139080043
The two converted files were nearly identical.
Instead of continuing that duplication, I merged them
into a single traceback.go.
Tested on arm, amd64, amd64p32, and 386.
LGTM=r
R=golang-codereviews, remyoudompheng, dave, r
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/134200044
The code I wrote originally works for trivial functions
that are inlined at a call site in another package,
because that was how I wrote my local test.
Make hex(x) work for non-inlinable functions too.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/140830043
Previously, if all connections were busy, we would always
re-prepare the statement on the connection we were assigned from
the pool. That meant that if all connections were busy most of the
time, the number of prepared statements for each connection would
keep increasing over time.
Instead, after getting a free connection, check to see if the
statement has already been prepared on it, and reuse the statement
handle if so.
LGTM=bradfitz
R=golang-codereviews, gobot, bradfitz
CC=golang-codereviews
https://golang.org/cl/116930043
It looks like this has just always been broken:
the race detector handles running Go code on g0 of the main thread
and on g0 of any extra threads created by non-Go code, but it does
not handle running Go code on g0 of non-main threads created by Go.
Handle that.
Should fix the race build failures on the dashboard.
We're running into this now because we are running more
and more Go code on g0.
TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/137910043
The file in repo has been updated recently, but all these changes
are gone off the web site now. It seems web site gets updated once
in a while, so we'll update our file occasionally.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/140780043
The exported Go definitions appearing in mprof.go are
copied verbatim from debug.go.
The unexported Go funcs and types are new.
The C Bucket type used a union and was not a line-for-line translation.
LGTM=remyoudompheng
R=golang-codereviews, remyoudompheng
CC=dvyukov, golang-codereviews, iant, khr, r
https://golang.org/cl/137040043
Adding the #include to defs.c makes it get processed
by cmd/dist, which writes out Go equivalent for all the
C data structures defined in defs.c.
This in turn makes it necessary to define the Plink type,
used in os_plan9.h, in os_plan9.go. Rename it to _Plink
to avoid being exported.
LGTM=0intro, iant
R=golang-codereviews, iant, 0intro
CC=golang-codereviews, r
https://golang.org/cl/132490043
uintptr is better when translating to Go,
and in a few places it's better in C too.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews, iant, khr
https://golang.org/cl/138980043
This change fixes the last known false negative of the race detector --
detection of races between mutating atomic operations and non-atomic operations.
Race runtime already has functions for precise modelling of various atomic operations,
so this change just forwards all atomic ops to race runtime
instead of poor man modeling in sync/atomic package.
Performance is also improved -- full sync/atomic tests run in 60s instead of 85s now.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/111310044
This is needed for callers to be able to keep track of the
writing position within a zip file. Otherwise it's not
possible to compute the size of headers, and the TOC isn't
written until the very end.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/134210043
NO CODE CHANGES HERE
The first conversion was not complete.
This CL doesn't make any actual changes,
but it inserts the missing mprof.goc code
as comments so that the next CL will have
useful diffs.
To make the diffs a bit more useful, removed
all semicolons, ->, and runtime· prefixes as well.
Also corrected order of a few functions in mprof.go
to match original order in mprof.goc.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews, iant, khr, r
https://golang.org/cl/134200043
The [568]c compilers no longer support packed structs, so
using them with -cdefs no longer works. Just commenting out
the test, rather than removing it, in case this needs to be
handled. It may be that -cdefs can go away entirely in the
future, in which case so can this directory.
LGTM=mdempsky
R=rsc, mdempsky
CC=golang-codereviews
https://golang.org/cl/136030043
Make the definition of the EpollEvent data field consistent
across architectures, adapt the other use of it in
netpoll_epoll for the new definition, and use uint64 rather
than uintptr.
LGTM=dave
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/137890043
We can't translate misaligned things to Go, so start rejecting them in C.
The only one in any build appears to be EpollEvent on linux/amd64.
Fix that.
LGTM=r
R=golang-codereviews, r, dvyukov
CC=golang-codereviews, iant
https://golang.org/cl/137020043
In an earlier CL I wrote a separate Go-only version, but that broke Plan 9,
because the Go-only version assumed a non-Plan 9 system.
Translate the real ones instead.
LGTM=r
R=golang-codereviews, r
CC=0intro, golang-codereviews, iant, khr
https://golang.org/cl/140050044
Under the race detector most of the samples go into race runtime,
because of that freebsd race builder constantly fails on this test.
LGTM=bradfitz, rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews, minux
https://golang.org/cl/133370043
Fixes script used to sanity-check the heading-detection heuristic of go/doc.
Fixes#8467.
LGTM=gri
R=golang-codereviews, gobot, gri
CC=golang-codereviews
https://golang.org/cl/128720043
Tested on linux/amd64 too this time.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=dave, golang-codereviews, iant, rsc
https://golang.org/cl/140050043
The net/http package supports setting the HTTP Authorization header
using the Basic Authentication Scheme as defined in RFC 2617, but does
not provide support for extracting the username and password from an
authenticated request using the Basic Authentication Scheme.
Add BasicAuth method to *http.Request that returns the username and
password from authenticated requests using the Basic Authentication
Scheme.
Fixes#6779.
LGTM=bradfitz
R=golang-codereviews, josharian, bradfitz, alberto.garcia.hierro, blakesgentry
CC=golang-codereviews
https://golang.org/cl/76540043
In CL 131450043, which raised it to 160,
I'd raise it to 192 if necessary.
Apparently it is necessary on windows/amd64.
One note for those concerned about the growth:
in the old segmented stack world, we wasted this much
space at the bottom of every stack segment.
In the new contiguous stack world, each goroutine has
only one stack segment, so we only waste this much space
once per goroutine. So even raising the limit further might
still be a net savings.
Fixes windows/amd64 build.
TBR=r
CC=golang-codereviews
https://golang.org/cl/132480043
Renaming the C SysAlloc will let Go define a prototype without exporting it.
For use in cpuprof.goc's translation to Go.
LGTM=mdempsky
R=golang-codereviews, mdempsky
CC=golang-codereviews, iant
https://golang.org/cl/140060043
Actually it mostly deletes code -- alg.print and alg.copy go away.
There was only one usage of alg.print for debug purposes.
Alg.copy is used in chan.goc, but Keith replaces them with
memcopy during conversion, so alg.copy is not needed as well.
Converting them would be significant amount of work
for no visible benefit.
LGTM=crawshaw, rsc, khr
R=golang-codereviews, crawshaw, khr
CC=golang-codereviews, rsc
https://golang.org/cl/139930044
preparing for the syscall package freeze.
the change for issue 8218 is only applied to go.sys/unix.
««« original CL description
syscall: implement setresuid(2) and setresgid(2) on OpenBSD/FreeBSD/DragonflyBSD
Fixes#8218.
LGTM=iant
R=golang-codereviews, iant, minux
CC=golang-codereviews
https://golang.org/cl/107150043
»»»
LGTM=r
R=r, iant, golang-codereviews
CC=golang-codereviews
https://golang.org/cl/138840044
Prevents non-rooted queries with > ndots dots from being tried twice on error.
Fixes#8616.
Benchmark results on linux/amd64
benchmark old ns/op new ns/op delta
BenchmarkGoLookupIPNoSuchHost 8212394 4413293 -46.26%
benchmark old allocs new allocs delta
BenchmarkGoLookupIPNoSuchHost 216 108 -50.00%
benchmark old bytes new bytes delta
BenchmarkGoLookupIPNoSuchHost 17460 8726 -50.02%
LGTM=iant, mikioh.mikioh
R=golang-codereviews, iant, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/137870043
It is anyway, just an allocated one.
Giving it a sized type makes Go access nicer.
LGTM=iant
R=dvyukov, iant
CC=golang-codereviews
https://golang.org/cl/139960043
I had to rename Kevent and Sigaction to avoid the functions of the
same (lowercase) name.
LGTM=iant, r
R=golang-codereviews, r, iant, aram.h
CC=dvyukov, golang-codereviews, khr
https://golang.org/cl/140740043
Signer is an interface to support opaque private keys.
These keys typically result from being kept in special hardware
(i.e. a TPM) although sometimes operating systems provide a
similar interface using process isolation for security rather
than hardware boundaries.
This changes provides interfaces for representing them and
alters crypto/tls so that client certificates can use
opaque keys.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews, jdeprez
https://golang.org/cl/114680043
Needless except that the api tool complains. We could fix that issue instead.
TBR=bradfitz
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/133290043
Run it right before main.init.
There is still some runtime initialization that
happens before runtime.init, and some of that
may call into Go code (for example to acquire locks)
so this timing is not perfect, but I believe it is the
best we can do.
This came up because global variables intialized
to func values are done in the generated init code,
not in the linker.
LGTM=dvyukov
R=dvyukov
CC=golang-codereviews, iant, khr, r
https://golang.org/cl/135210043
As part of the translation of the runtime, we need to rewrite
C printf calls to Go print calls. Consider this C printf:
runtime·printf("[signal %x code=%p addr=%p pc=%p]\n",
g->sig, g->sigcode0, g->sigcode1, g->sigpc);
Today the only way to write that in Go is:
print("[signal ")
printhex(uint64(g->sig))
print(" code=")
printhex(uint64(g->sigcode0))
print(" addr=")
printhex(uint64(g->sigcode1))
print(" pc=")
printhex(uint64(g->sigpc))
print("]\n")
(That's nearly exactly what runtime code looked like in C before
I added runtime·printf.)
This CL recognizes the unexported type runtime.hex as an integer
that should be printed in hexadecimal instead of decimal.
It's a little kludgy, but it's restricted to package runtime.
Other packages can define type hex with no effect at all.
Now we can translate that original printf as the more compact:
print("[signal ", hex(g->sig), " code=", hex(g->sigcode0),
" addr=", hex(g->sigcode1), " pc=", hex(g->sigpc), "]\n")
LGTM=r, iant
R=r, iant
CC=golang-codereviews
https://golang.org/cl/133220043
ErrorContext now has all the information it needs from the Node,
rather than depending on the template that contains it. This makes
it easier for html/template to generate correct locations in its
error messages.
Updated html/template to use this ability where it is easy, which is
not everywhere, but more work can probably push it through.
Fixes#8577.
LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/130620043
Remove C version of GC.
Convert freeOSMemory to Go.
Restore g0 check in GC.
Remove unknownGCPercent check in GC,
it's initialized explicitly now.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews, khr
https://golang.org/cl/139910043
Breaks on Plan 9, apparently.
The other systems must not run sprintf during all.bash.
I'd write a test but it's all going away.
TBR=r
CC=0intro, golang-codereviews
https://golang.org/cl/133260044
I've started with just one function with 8 arguments,
but stdcall is called from nosplit functions
and 8 args overflow nosplit area.
LGTM=aram, alex.brainman
R=golang-codereviews, aram, alex.brainman, dave
CC=golang-codereviews, iant, khr, rsc
https://golang.org/cl/135090043
PNG filters are applied to get better compression ratio.
It does not make sense to apply them if we are not going
to compress.
LGTM=nigeltao
R=nigeltao
CC=golang-codereviews
https://golang.org/cl/137830043
Also fix a bunch of bugs:
1. Accesses to last_gc must be atomic (it's int64).
2. last_gc still can be 0 during first checks in sysmon, check for 0.
3. forcegc.g can be unitialized when sysmon accesses it:
forcegc.g is initialized by main goroutine (forcegc.g = newproc1(...)),
and main goroutine is unsynchronized with both sysmon and forcegc goroutine.
Initialize forcegc.g in the forcegc goroutine itself instead.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/136770043
Clang 3.2 and older (as shipped with OS X Mountain Lion and older)
outputs ambiguous DWARF debug info that makes it impossible for us to
reconstruct accurate type information as required for this test.
Fixes#8611.
LGTM=rsc
R=r, rsc, minux
CC=golang-codereviews
https://golang.org/cl/135990043
Shrinks the text segment size by about 1.5% for the "go", "gofmt",
and "camlistored" commands on linux/amd64.
Before:
$ size go gofmt camlistored
text data bss dec hex filename
6506842 136996 105784 6749622 66fdb6 go
2376046 85232 90984 2552262 26f1c6 gofmt
17051050 190256 130320 17371626 10911ea camlistored
After:
$ size go gofmt camlistored
text data bss dec hex filename
6403034 136996 105784 6645814 656836 go
2331118 85232 90984 2507334 264246 gofmt
16842586 190256 130320 17163162 105e39a camlistored
Fixes#8604.
LGTM=rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/137790043
This is a reapplication of CL 93520045 (changeset 5012df7fac58)
since that was lost during the move to an internal package.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/134020043
In revision 05c3fee13eb3, openbsd/386's tfork implementation was
accidentally changed in one instruction from using the "params"
parameter to using the "psize" parameter.
While here, OpenBSD's __tfork system call returns a pid_t which is an
int32 on all OpenBSD architectures, so change runtime.tfork's return
type from int64 to int32 and update the assembly implementations
accordingly.
LGTM=iant
R=rsc, iant
CC=golang-codereviews, jsing
https://golang.org/cl/133190043
Package addition.
PositionFor permits access to both, positions
adjusted by //line comments (like the Position
accessors), and unadjusted "raw" positions
unaffected by //line comments.
Raw positions are required for correct formatting
of source code via go/printer which until now had
to manually fix adjusted positions.
Fixes#7702.
LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/135110044
Preparation for fixing issue 5769 (method selectors
do not auto-dereference): The actual fix may require
some cleanups in all these sections, and syntactically,
method expressions and method values are selector
expressions. Moving them next to each other so that
it's easy to see the actual changes (next CL).
No content changes besides the section moves.
LGTM=iant, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/132300043
This is getting a little annoying, but once the runtime structs are
being defined in Go, these will go away. So it's only a temporary cost.
TBR=bradfitz
CC=golang-codereviews
https://golang.org/cl/135940043
'range hash' makes a copy of the hash array in the stack, creating
a very large stack frame. It's just the right amount that it
uses most but not all of the total stack size. If you have a lot
of environment variables, like the builders, then this is too
much and the g0 stack runs out of space.
TBR=bradfitz
CC=golang-codereviews
https://golang.org/cl/132350043
In order to support different compression levels, make the
encoder type public, and add an Encoder method to it.
Fixes#8499.
LGTM=nigeltao
R=nigeltao, ruiu
CC=golang-codereviews
https://golang.org/cl/129190043
I changed all the NACL_SYSJMP to NACL_SYSCALL in
an earlier CL, but I missed the fact that NACL_SYSCALL
will push another return PC on the stack, so that the
arguments will no longer be in the right place.
Since we have to make our own call, we also have to
copy the arguments. Do that.
Fixes nacl/386 build.
TBR=minux
CC=golang-codereviews
https://golang.org/cl/135050044
This will allow structs containing Efaces in C to be
manipulated as structs containing real interfaces in Go.
The eface struct is still defined for use by Go code.
LGTM=iant
R=golang-codereviews, iant
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/133980044
Mutex is consistent with package sync, and when in the
unexported Go form it avoids having a conflcit between
the type (now mutex) and the function (lock).
LGTM=iant
R=golang-codereviews, iant
CC=dvyukov, golang-codereviews, r
https://golang.org/cl/133140043
This adds the minimal support for AArch64/arm64 relocations
needed to get cgo to work (when an isomorphic patch is applied
to gccgo) and a test.
This change uses the "AAarch64" name for the architecture rather
than the more widely accepted "arm64" because that's the name that
the relevant docs from ARM such as
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf
all use.
Fixes#8533.
LGTM=iant
R=golang-codereviews, aram, gobot, iant, minux
CC=golang-codereviews
https://golang.org/cl/132000043
NaCl requires the addition of a 32-byte "halt sled" at the end
of the text segment. This means that segtext.len is actually
32 bytes shorter than reality. The computation of the file offset
of the end of the data segment did not take this 32 bytes into
account, so if len and len+32 rounded up (by 64k) to different
values, the symbol table overwrote the last page of the data
segment.
The last page of the data segment is usually the C .string
symbols, which contain the strings used in error prints
by the runtime. So when this happens, your program
probably crashes, and then when it does, you get binary
garbage instead of all the usual prints.
The chance of hitting this with a randomly sized text segment
is 32 in 65536, or 1 in 2048.
If you add or remove ANY code while trying to debug this
problem, you're overwhelmingly likely to bump the text
segment one way or the other and make the bug disappear.
Correct all the computations to use segdata.fileoff+segdata.filelen
instead of trying to rederive segdata.fileoff.
This fixes the failure during the nacl/amd64p32 build.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/135050043
The NaCl "system calls" were assumed to have a compatible
return convention with the C compiler, and we were using
tail jumps to those functions. Don't do that anymore.
Correct mistake introduced in newstackcall duringconversion
from (SP) to (FP) notation. (Actually this fix, in asm_amd64p32.s,
slipped into the C compiler change, but update the name to
match what go vet wants.)
Correct computation of caller stack pointer in morestack:
on amd64p32, the saved PC is the size of a uintreg, not uintptr.
This may not matter, since it's been like this for a while,
but uintreg is the correct one. (And on non-NaCl they are the same.)
This will allow the NaCl build to get much farther.
It will probably still not work completely.
There's a bug in 6l that needs fixing too.
TBR=minux
CC=golang-codereviews
https://golang.org/cl/134990043
runtime._sfloat2 now returns the lr value on the stack, not R0.
Credit to Russ Cox for the fix.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/133120045
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
nanotime1 is not a Go function and must not store its result at 0(FP).
That overwrites some data owned by the caller.
TBR=aram
CC=golang-codereviews
https://golang.org/cl/138730043
Windows needs the return result in AX, but runtime.sighandler
no longer stores it in AX. Load it back during the assembly trampoline.
TBR=brainman
CC=golang-codereviews
https://golang.org/cl/133980043
The Go calling convention uses more stack space than C.
On 64-bit systems we've been right up against the limit
(128 bytes, so only 16 words) and doing awful things to
our source code to work around it. Instead of continuing
to do awful things, raise the limit to 160 bytes.
I am prepared to raise the limit to 192 bytes if necessary,
but I think this will be enough.
Should fix current link-time stack overflow errors on
- nacl/arm
- netbsd/amd64
- openbsd/amd64
- solaris/amd64
- windows/amd64
TBR=r
CC=golang-codereviews, iant
https://golang.org/cl/131450043
To date, the C compilers and Go compilers differed only in how
values were returned from functions. This made it difficult to call
Go from C or C from Go if return values were involved. It also made
assembly called from Go and assembly called from C different.
This CL changes the C compiler to use the Go conventions, passing
results on the stack, after the arguments.
[Exception: this does not apply to C ... functions, because you can't
know where on the stack the arguments end.]
By doing this, the CL makes it possible to rewrite C functions into Go
one at a time, without worrying about which languages call that
function or which languages it calls.
This CL also updates all the assembly files in package runtime to use
the new conventions. Argument references of the form 40(SP) have
been rewritten to the form name+10(FP) instead, and there are now
Go func prototypes for every assembly function called from C or Go.
This means that 'go vet runtime' checks effectively every assembly
function, and go vet's output was used to automate the bulk of the
conversion.
Some functions, like seek and nsec on Plan 9, needed to be rewritten.
Many assembly routines called from C were reading arguments
incorrectly, using MOVL instead of MOVQ or vice versa, especially on
the less used systems like openbsd.
These were found by go vet and have been corrected too.
If we're lucky, this may reduce flakiness on those systems.
Tested on:
darwin/386
darwin/amd64
linux/arm
linux/386
linux/amd64
If this breaks another system, the bug is almost certainly in the
sys_$GOOS_$GOARCH.s file, since the rest of the CL is tested
by the combination of the above systems.
LGTM=dvyukov, iant
R=golang-codereviews, 0intro, dave, alex.brainman, dvyukov, iant
CC=golang-codereviews, josharian, r
https://golang.org/cl/135830043
Every change to g->atomicstatus is now done atomically so that we can
ensure that all gs pass through a gc safepoint on demand. This allows
the GC to move from one phase to the next safely. In some phases the
stack will be scanned. This CL only deals with the infrastructure that
allows g->atomicstatus to go from one state to another. Future CLs
will deal with scanning and monitoring what phase the GC is in.
The major change was to moving to using a Gscan bit to indicate that
the status is in a scan state. The only bug fix was in oldstack where
I wasn't moving to a Gcopystack state in order to block scanning until
the new stack was in place. The proc.go file is waiting for an atomic
load instruction.
LGTM=rsc
R=golang-codereviews, dvyukov, josharian, rsc
CC=golang-codereviews, khr
https://golang.org/cl/132960044
Update #8527
Fixes two warnings:
src/cmd/gc/mparith3.c:255:10: runtime error: shift exponent 52 is too large for 32-bit type 'int'
src/cmd/gc/mparith3.c:254:14: runtime error: shift exponent 52 is too large for 32-bit type 'int'
LGTM=rsc
R=r, dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/134940044
Also make genzabbrs.go more self-contained.
Also run it (on Linux; does that matter?) to update the table.
LGTM=rsc
R=rsc, alex.brainman
CC=golang-codereviews
https://golang.org/cl/128350044
I noticed that 5g doesn't flush the float64 result back to the stack, hence the change in the function signature. I'm wondering if I should also change the signature for the other two functions.
LGTM=rsc
R=minux, josharian, rsc
CC=golang-codereviews
https://golang.org/cl/132990044
There are both many callers and many implementations of these
interfaces, so make the contract explicit. Callers generally
assume this, and at least the standard library and other
implementations obey this, but it's never stated explicitly,
making it somewhat risky to assume.
LGTM=gri, rsc
R=golang-codereviews, gri
CC=golang-codereviews, r, rsc
https://golang.org/cl/132150043
Also: use 0x644 file permission if a new file
is created (should not happen anymore, though).
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/126610044
Simplify the invocation (and speed it up substantially) in preparation
for move to go generate.
LGTM=bradfitz, mpvl
R=mpvl, bradfitz, josharian
CC=golang-codereviews
https://golang.org/cl/135790043
Once and for all.
Broken in cl/108640043.
I've messed it before. To test scavenger-related changes
one needs to alter the constants during final testing.
And then it's very easy to submit with the altered constants.
LGTM=rsc
R=golang-codereviews
CC=golang-codereviews, rsc
https://golang.org/cl/136720044
Deleted in cl/123700044.
I am not sure whether I need to restore it,
or delete rest of the uses...
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/129580043
Before, a slice with cap=0 or a string with len=0 might have its
base pointer pointing beyond the actual slice/string data into
the next block. The collector had to ignore slices and strings with
cap=0 in order to avoid misinterpreting the base pointer.
Now, a slice with cap=0 or a string with len=0 still has a base
pointer pointing into the actual slice/string data, no matter what.
The collector can now always scan the pointer, which means
strings and slices are no longer special.
Fixes#8404.
LGTM=khr, josharian
R=josharian, khr, dvyukov
CC=golang-codereviews
https://golang.org/cl/112570044
Fixes test failure in build, probably a good idea anyway.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/131210043
It was respected by unmarshal, but not marshal, so they didn't
round-trip.
Fixes#8582
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/132960043
A whole thread is too much for background scavenger that sleeps all the time anyway.
We already have sysmon thread that can do this work.
Also remove g->isbackground and simplify enter/exitsyscall.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews, khr, rlh
https://golang.org/cl/108640043
Normally, an expression of the form x.f or *y can be reordered
with function calls and communications.
Select is stricter than normal: each channel expression is evaluated
in source order. If you have case <-x.f and case <-foo(), then if the
evaluation of x.f causes a panic, foo must not have been called.
(This is in contrast to an expression like x.f + foo().)
Enforce this stricter ordering.
Fixes#8336.
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews, r
https://golang.org/cl/126570043
Reduce duration of critical section,
make pcbuf local to function.
LGTM=rsc
R=golang-codereviews
CC=golang-codereviews, rsc
https://golang.org/cl/102600043
Update #8525
Some temporary variables that were fully registerized nevertheless had stack space allocated for them because the Addrs were still marked as having associated nodes.
Distribution of stack space reserved for temporary variables while running make.bash (6g):
BEFORE
40.89% 7026 allocauto: 0 to 0
7.83% 1346 allocauto: 0 to 24
7.22% 1241 allocauto: 0 to 8
6.30% 1082 allocauto: 0 to 16
4.96% 853 allocauto: 0 to 56
4.59% 789 allocauto: 0 to 32
2.97% 510 allocauto: 0 to 40
2.32% 399 allocauto: 0 to 48
2.10% 360 allocauto: 0 to 64
1.91% 328 allocauto: 0 to 72
AFTER
48.49% 8332 allocauto: 0 to 0
9.52% 1635 allocauto: 0 to 16
5.28% 908 allocauto: 0 to 48
4.80% 824 allocauto: 0 to 32
4.73% 812 allocauto: 0 to 8
3.38% 581 allocauto: 0 to 24
2.35% 404 allocauto: 0 to 40
2.32% 399 allocauto: 0 to 64
1.65% 284 allocauto: 0 to 56
1.34% 230 allocauto: 0 to 72
LGTM=rsc
R=rsc
CC=dave, dvyukov, golang-codereviews, minux
https://golang.org/cl/126160043
cmd/6g has been doing this for a long time.
Arrays are still problematic on 5g because the addressing
for t[0] where local var t has type [3]uintptr takes the address of t.
That's issue 8125.
Fixes#8123.
LGTM=josharian
R=josharian, dave
CC=golang-codereviews
https://golang.org/cl/102890046
CL 130240043 did this but broke ARM, because
it made newErrorCString start allocating, so we rolled
it back in CL 133810043.
CL 133820043 removed that allocation.
Try again.
Fixes#8405.
LGTM=bradfitz, dave
R=golang-codereviews, bradfitz
CC=dave, golang-codereviews, r
https://golang.org/cl/133830043
Now 'go vet runtime' only shows:
malloc.go:200: possible misuse of unsafe.Pointer
malloc.go:214: possible misuse of unsafe.Pointer
malloc.go:250: possible misuse of unsafe.Pointer
stubs.go:167: possible misuse of unsafe.Pointer
Those are all unavoidable.
LGTM=josharian
R=golang-codereviews, dvyukov, josharian
CC=dave, golang-codereviews
https://golang.org/cl/135730043
It now serves as an example for go generate as well as for yacc.
NOTE: Depends on go generate, which is not yet checked in.
This is a proof of concept of the approach.
That is https://golang.org/cl/125580044.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/125620044
This is based on the crash dump provided by Alan
and on mental experiments:
sweep 0 74
fatal error: gc: unswept span
runtime stack:
runtime.throw(0x9df60d)
markroot(0xc208002000, 0x3)
runtime.parfordo(0xc208002000)
runtime.gchelper()
I think that when we moved all stacks into heap,
we introduced a bunch of bad data races. This was later
worsened by parallel stack shrinking.
Observation 1: exitsyscall can allocate a stack from heap at any time (including during STW).
Observation 2: parallel stack shrinking can (surprisingly) grow heap during marking.
Consider that we steadily grow stacks of a number of goroutines from 8K to 16K.
And during GC they all can be shrunk back to 8K. Shrinking will allocate lots of 8K
stacks, and we do not necessary have that many in heap at this moment. So shrinking
can grow heap as well.
Consequence: any access to mheap.allspans in GC (and otherwise) must take heap lock.
This is not true in several places.
Fix this by protecting accesses to mheap.allspans and introducing allspans cache for marking,
similar to what we use for sweeping.
LGTM=rsc
R=golang-codereviews, rsc
CC=adonovan, golang-codereviews, khr, rlh
https://golang.org/cl/126510043
The low-level implementation of divide on ARM assumes that
it can panic with an error created by newErrorCString without
allocating. If we make interface data words require pointer values,
the current definition would require an allocation when stored
in an interface. Changing the definition to use unsafe.Pointer
instead of uintptr avoids the allocation. This change is okay
because the field really is a pointer (to a C string in rodata).
Update #8405.
This should make CL 133830043 safe to try again.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=dave, golang-codereviews, r
https://golang.org/cl/133820043
This change broke divmod.go on all arm platforms.
««« original CL description
cmd/gc: change interface representation: only pointers in data word
Note that there are various cleanups that can be made if we keep
this change, but I do not want to start making changes that
depend on this one until the 1.4 cycle closes.
Fixes#8405.
LGTM=r
R=golang-codereviews, adg, r, bradfitz
CC=golang-codereviews, iant
https://golang.org/cl/130240043
»»»
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/133810043
This is a very dumb translation to keep the code as close to the original C as possible.
LGTM=rsc
R=khr, minux, rsc, josharian
CC=golang-codereviews
https://golang.org/cl/126490043
Note that there are various cleanups that can be made if we keep
this change, but I do not want to start making changes that
depend on this one until the 1.4 cycle closes.
Fixes#8405.
LGTM=r
R=golang-codereviews, adg, r, bradfitz
CC=golang-codereviews, iant
https://golang.org/cl/130240043
This makes newproc invisible to the GC. This is a pretty simple change since parts of newproc already depends on being run on the M stack.
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews, khr
https://golang.org/cl/129520043
The current code is correct, but vet does not understand it:
asm_amd64.s:963: [amd64] invalid MOVL of ret+0(FP); int64 is 8-byte value
asm_amd64.s:964: [amd64] invalid offset ret+4(FP); expected ret+0(FP)
LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/125200044
Fix issue by always appending newline after user input, before
the closing curly bracket. The adjust func is modified to remove
this new newline.
Add test case (it fails before CL, passes after).
Fixes#8411.
LGTM=gri
R=golang-codereviews, bradfitz, josharian, gri
CC=golang-codereviews
https://golang.org/cl/124700043
Fixes#8503.
Thanks to no.smile.face for the original report.
LGTM=bradfitz, r, ruiu
R=bradfitz, ruiu, r
CC=golang-codereviews
https://golang.org/cl/132730043
Add gofmt.go and gofmt_test.go as they are part of the test data set.
See CL 130440043.
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews
https://golang.org/cl/132820044
1) Interpret a comment of the form
//gofmt <flags>
in test files to drive the respective
gofmt command. Eliminates the need to
enumerate all test files in the test
harness.
2) Added -update flag to make it easier
to update test cases.
LGTM=josharian
R=golang-codereviews, josharian
CC=golang-codereviews
https://golang.org/cl/130440043
Update #8527
Fixes, src/cmd/6l/../ld/pcln.c:93:18: runtime error: left shift of negative value -2
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/127440043
This files were added accidentally and are
not required for running the tests (they
are produced by failing tests for easier
debugging).
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/131030044
Fixes compilation of runtime on Solaris where the inner struct
was not called "_4_".
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/129460043
Australian timezones abbreviation for standard and daylight saving time were recently
changed from EST for both to AEST and AEDT in the icann tz database (see changelog
on www.iana.org/time-zones).
A test in the time package was written to check that the ParseInLocation function
understand that Feb EST and Aug EST are different time zones, even though they are
both called EST. This is no longer the case, and the Date function now returns
AEST or AEDT for australian tz on every Linux system with an up to date tz database
(and this makes the test fail).
Since I wasn't able to find another country that 1) uses daylight saving and 2) has
the same abbreviation for both on tzdata, I changed the test to make sure that
ParseInLocation does not get confused when it parses, in different locations, two
dates with the same abbreviation (this was suggested in the mailing list).
Fixes#8547.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/130920043
Cleanup before converting to Go.
Fortunately nobody using it, because it is incorrect:
monotonic runtime time instead of claimed real time.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/129480043
These are required for chans, semaphores, timers, etc.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/123640043
UndefinedBehaviorSanitizer claims it is UB in C:
src/cmd/gc/racewalk.c:422:37: runtime error: member access within null pointer of type 'Node' (aka 'struct Node')
src/cmd/gc/racewalk.c:423:37: runtime error: member access within null pointer of type 'Node' (aka 'struct Node')
LGTM=rsc
R=dave, rsc
CC=golang-codereviews
https://golang.org/cl/125570043
Init GC later as it needs to read GOGC env var.
Fixes#8562.
LGTM=daniel.morsing, rsc
R=golang-codereviews, daniel.morsing, rsc
CC=golang-codereviews, khr, rlh
https://golang.org/cl/130990043
Calling ReadMemStats which does stoptheworld on m0 holding locks
was not a good idea.
Stoptheworld holding locks is a recipe for deadlocks (added check for this).
Stoptheworld on g0 may or may not work (added check for this as well).
As far as I understand scavenger will print incorrect numbers now,
as stack usage is not subtracted from heap. But it's better than deadlocking.
LGTM=khr
R=golang-codereviews, rsc, khr
CC=golang-codereviews, rlh
https://golang.org/cl/124670043
zsyscall_windows_386.go and zsyscall_windows_amd64.go contain same bytes
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/124640043
The existing lock needed to be held longer. If a timeout occured
while writing (but after the guarded timeout check), the writes
would clobber a future connection's buffer.
Also remove a harmless warning by making Write also set the
flag that headers were sent (implicitly), so we don't try to
write headers later (a no-op + warning) on timeout after we've
started writing.
Fixes#8414Fixes#8209
LGTM=ruiu, adg
R=adg, ruiu
CC=golang-codereviews
https://golang.org/cl/123610043
Half the code in the garbage collector accesses the bitmap
as an array of bytes instead of as an array of uintptrs.
This is tricky to do correctly in a portable fashion,
it breaks on big-endian systems.
Make the bitmap a byte array.
Simplifies markallocated, scanblock and span sweep along the way,
as we don't need to recalculate bitmap position for each word.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/125250043
We allocate scannable memory w/o type only in few places in runtime.
All these cases are not-performance critical (e.g. G or finq args buffer),
and in long term they all need to go away.
It's not worth it to have special code for this case in mallocgc.
So use special fake "notype" type for such allocations.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/127450044
Currently goroutines in onM can't be copied/shrunk
(including the very goroutine that triggers GC).
Special case onM to allow copying.
LGTM=daniel.morsing, khr
R=golang-codereviews, daniel.morsing, khr, rsc
CC=golang-codereviews, rlh
https://golang.org/cl/124550043
Newly allocated memory is subtracted from inuse, while it was never added to inuse.
Span leftovers are subtracted from both inuse and idle,
while they were never added.
Fixes#8544.
Fixes#8430.
LGTM=khr, cookieo9
R=golang-codereviews, khr, cookieo9
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/130200044
We need to change the interface value representation for
concurrent garbage collection, so that there is no ambiguity
about whether the data word holds a pointer or scalar.
This CL does NOT make any representation changes.
Instead, it removes representation assumptions from
various pieces of code throughout the tree.
The isdirectiface function in cmd/gc/subr.c is now
the only place that decides that policy.
The policy propagates out from there in the reflect
metadata, as a new flag in the internal kind value.
A follow-up CL will change the representation by
changing the isdirectiface function. If that CL causes
problems, it will be easy to roll back.
Update #8405.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/129090043
The change to pc-relative addressing will make this illegal.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/129890043
Update #8527
Fixes, cmd/6g/reg.c:847:24: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
LGTM=minux, rsc
R=minux, rsc
CC=dvyukov, golang-codereviews
https://golang.org/cl/129290043
type T byte
func (T) String() string { return "X" }
fmt.Sprintf("%s", []T{97, 98, 99, 100}) == "abcd"
fmt.Sprintf("%x", []T{97, 98, 99, 100}) == "61626364"
fmt.Sprintf("%v", []T{97, 98, 99, 100}) == "[X X X X]"
This change makes the last case print correctly.
Before, it would have been "[97 98 99 100]".
Fixes#8360.
LGTM=r
R=r, dan.kortschak
CC=golang-codereviews
https://golang.org/cl/129330043
Improve performance of move-to-front by using cache-friendly
copies instead of doubly-linked list. Simplify so that the
underlying slice is the object. Remove the n=0 special case,
which was actually slower with the copy approach.
benchmark old ns/op new ns/op delta
BenchmarkDecodeDigits 26429714 23859699 -9.72%
BenchmarkDecodeTwain 76684510 67591946 -11.86%
benchmark old MB/s new MB/s speedup
BenchmarkDecodeDigits 1.63 1.81 1.11x
BenchmarkDecodeTwain 1.63 1.85 1.13x
Updates #6754.
LGTM=adg, agl, josharian
R=adg, agl, josharian
CC=golang-codereviews
https://golang.org/cl/131840043
Currently we do the following dance after sweeping a span:
1. lock mcentral
2. remove the span from a list
3. unlock mcentral
4. unmark span
5. lock mheap
6. insert the span into heap
7. unlock mheap
8. lock mcentral
9. observe empty list
10. unlock mcentral
11. lock mheap
12. grab the span
13. unlock mheap
14. mark span
15. lock mcentral
16. insert the span into empty list
17. unlock mcentral
This change short-circuits this sequence to nothing,
that is, we just cache and use the span after sweeping.
This gives us functionality similar (even better) to tcmalloc's transfer cache.
benchmark old ns/op new ns/op delta
BenchmarkMalloc8 22.2 19.5 -12.16%
BenchmarkMalloc16 31.0 26.6 -14.19%
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/119550043
Mallocgc must be atomic wrt GC, but for performance reasons
don't acquirem/releasem on fast path. The code does not have
split stack checks, so it can't be preempted by GC.
Functions like roundup/add are inlined. And onM/racemalloc are nosplit.
Also add debug code that checks these assumptions.
benchmark old ns/op new ns/op delta
BenchmarkMalloc8 20.5 17.2 -16.10%
BenchmarkMalloc16 29.5 27.0 -8.47%
BenchmarkMallocTypeInfo8 31.5 27.6 -12.38%
BenchmarkMallocTypeInfo16 34.7 30.9 -10.95%
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/123100043
Fixes#8480.
This CL reapplies CL 114420043. This attempt doesn't blow up when encountering hidden symbols.
LGTM=minux
R=minux
CC=golang-codereviews
https://golang.org/cl/128310043
When building golang, the environment variable GOROOT_FINAL can be set
to indicate a different installation location from the build
location. This works fine, except that the goc2c build step embeds
line numbers in the resulting c source files that refer to the build
location, no the install location.
This would not be a big deal, except that in turn the linker uses the
location of runtime/string.goc to embed the gdb script in the
resulting binary and as a net result, the debugger now complains that
the script is outside its load path (it has the install location
configured).
See https://code.google.com/p/go/issues/detail?id=8524 for the full
description.
Fixes#8524.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/128230046
The "simpler faster garbage collector" is full of little-endian assumptions.
Instead of trying to correct all the mistakes, just give in and make
everything use bytes.
LGTM=minux
R=minux
CC=dvyukov, golang-codereviews
https://golang.org/cl/124400043
bv.data is an array of uint32s but the code was using
offsets computed for an array of bytes.
Add a test for stack GC info.
Fixes#8531.
LGTM=rsc
R=golang-codereviews
CC=golang-codereviews, khr, rsc
https://golang.org/cl/124450043
Fixes#8495.
CL 128260043 updated the definition of syscall.GetPageSize to report 64k for power64 and power64le. This CL cleans up the last place where the page size was defined as 4k.
LGTM=minux
R=rsc, minux
CC=golang-codereviews
https://golang.org/cl/123520043
This runs once. There is no need for inscrutable algorithms.
Also it doesn't compile correctly with 9c.
LGTM=minux
R=minux
CC=golang-codereviews
https://golang.org/cl/130000043
E.g., here's the new "go build" output:
$ go build misc/cgo/errors/issue8442.go
# command-line-arguments
could not determine kind of name for C.issue8442foo
gcc errors for preamble:
misc/cgo/errors/issue8442.go:11:19: error: unknown type name 'UNDEF'
Fixes#8442.
LGTM=iant
R=iant, alex.brainman
CC=golang-codereviews
https://golang.org/cl/129160043
On the machine I'm using, the hardware page size seems to be 64 kB.
Make ELF rounding and mmap quantum 64 kB to match.
Error numbers returned from kernel are positive; do not negate.
Implement stubs for math/big.
LGTM=minux
R=minux
CC=golang-codereviews
https://golang.org/cl/124300043
In cgo, now that recursive calls to typeConv.Type() always work,
we can more robustly calculate the array sizes based on the size
of our element type.
Also, in debug/dwarf, the decision to call zeroType is made
based on a type's usage within a particular struct, but dwarf.Type
values are cached in typeCache, so the modification might affect
uses of the type in other structs. Current compilers don't appear
to share DWARF type entries for "[]foo" and "[0]foo", but they also
don't consistently share type entries in other cases. Arguably
modifying the types is an improvement in some cases, but varying
translated types according to compiler whims seems like a bad idea.
Lastly, also in debug/dwarf, zeroType only needs to rewrite the
top-level dimension, and only if the rest of the array size is
non-zero.
Fixes#8428.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/127980043
Restore https://golang.org/cl/41040043 after GC rewrite.
Original description:
On the plus side, we don't need to change the bits on malloc and free.
On the downside, we need to mark objects in the free lists during GC.
But the free lists are small at GC time, so it should be a net win.
benchmark old ns/op new ns/op delta
BenchmarkMalloc8 21.9 20.4 -6.85%
BenchmarkMalloc16 31.1 29.6 -4.82%
LGTM=khr
R=khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/122280043
Those moves might be significant (e.g. narrowing or widening): on Power64,
we don't distinguish between MOVWD and MOVW.
This fixes divmode.go and bug447.go.
LGTM=rsc
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/125200043
Basically this cleanup replaces all the usage usages of strcmp() == 0,
found by the following command line:
$ grep -R strcmp cmd/dist | grep "0"
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/123330043
Copy main from 6a. Fixes various things, but the
main thing is the use of the new flag parser.
The go command expects to be able to use -trimpath
and not have it be interpreted as -t rimpath.
LGTM=minux
R=minux
CC=golang-codereviews
https://golang.org/cl/126100043
The file is used by assembly code to define symbols like NOSPLIT.
Having it hidden inside the cmd directory makes it hard to access
outside the standard repository.
Solution: As with a couple of other files used by cgo, copy the
file into the pkg directory and add a -I argument to the assembler
to access it. Thus one can write just
#include "textflag.h"
in .s files.
The names in runtime are not updated because in the boot sequence the
file has not been copied yet when runtime is built. All other .s files
in the repository are updated.
Changes to doc/asm.html, src/cmd/dist/build.c, and src/cmd/go/build.go
are hand-made. The rest are just the renaming done by a global
substitution. (Yay sam).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/128050043
This allows implementing address-of-global
as a pc-relative address instead of as a
32-bit integer constant.
LGTM=rminnich, iant
R=golang-codereviews, rminnich, iant
CC=golang-codereviews
https://golang.org/cl/128070045
This allows changing the addressing mode for constant
global addresses to use pc-relative addressing.
LGTM=rminnich, iant
R=golang-codereviews, rminnich, iant
CC=golang-codereviews
https://golang.org/cl/129830043
You talked me into it. This and other links should be updated
once the new import paths for the subrepos are established.
LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/124260043
Add a clause to the doc comment for the package and a
paragraph in the compatibility document explaining the
situation.
LGTM=bradfitz, adg, rsc
R=golang-codereviews, adg, bradfitz, minux, rsc
CC=golang-codereviews
https://golang.org/cl/129820043
codeblk and datblk were truncating their
arguments to int32. Don't do that.
LGTM=dvyukov, rminnich
R=iant, dvyukov, rminnich
CC=golang-codereviews
https://golang.org/cl/126050043
See golang.org/s/go14customimport for design.
Added case to deps_test to allow go/build to import regexp.
Not a new dependency, because go/build already imports go/doc
which imports regexp.
Fixes#7453.
LGTM=r
R=r, josharian
CC=golang-codereviews
https://golang.org/cl/124940043
It's unclear why we do this broken double-checked locking.
The mutex is not held for the whole duration of CPU profiling.
Fixes#8365.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/116290043
This function does not have a declaration/prototype in a.h, and it is used only
in buf.c, so it is local to it and thus can be marked as private by adding
'static' to it.
LGTM=iant
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/122300043
misc/cgo/testgodefs was added by revision d1cf884a594f, but not
add to run.bash.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/129760044
Without this CL, simply running mkall.sh for Linux will generate duplicated constants
for termios. I verified that after this CL, mkall.sh will generate almost identical
z* files for linux/amd64.
LGTM=rsc
R=rsc, iant, r
CC=golang-codereviews
https://golang.org/cl/124990043
This makes GCC behavior (and cgo build failures) deterministic.
Fixes#8487.
Ran this shell command on linux/amd64 (Ubuntu 12.04) before and
after this change:
for x in `seq 100`; do
go tool cgo -debug-gcc=true issue8441.go 2>&1 | md5sum
done | sort | uniq -c
Before:
67 2cdcb8c7c4e290f7d9009abc581b83dd -
10 9a55390df94f7cec6d810f3e20590789 -
10 acfad22140d43d9b9517bbc5dfc3c0df -
13 c337f8fee2304b3a8e3158a4362d8698 -
After:
100 785c316cbcbcd50896695050e2fa23c1 -
LGTM=minux, iant
R=golang-codereviews, bradfitz, minux, iant
CC=golang-codereviews
https://golang.org/cl/126990043
Credit to Rémy for finding and writing test case.
Fixes#8325.
LGTM=r
R=golang-codereviews, r
CC=dave, golang-codereviews, iant, remyoudompheng
https://golang.org/cl/124950043
The >>1 shift needs to happen before converting to int32, otherwise
large values will decode with an incorrect sign bit.
The <<31 shift can happen before or after, but before is consistent
with liblink and the go12symtab doc.
Bug demo at http://play.golang.org/p/jLrhPUakIu
LGTM=rsc
R=golang-codereviews, minux, rsc
CC=golang-codereviews
https://golang.org/cl/119630043
When formatting time zone offsets with seconds using the stdISO8601Colon
and stdNumColon layouts, the colon was missing between the hour and minute
parts.
Fixes#8497.
LGTM=r
R=golang-codereviews, iant, gobot, r
CC=golang-codereviews
https://golang.org/cl/126840043
On OS X 10.10 Yosemite, if you have a directory that can be returned
in a single getdirentries64 call (for example, a directory with one file),
and you read from the directory at EOF twice, you get EOF both times:
fd = open("dir")
getdirentries64(fd) returns data
getdirentries64(fd) returns 0 (EOF)
getdirentries64(fd) returns 0 (EOF)
But if you remove the file in the middle between the two calls, the
second call returns an error instead.
fd = open("dir")
getdirentries64(fd) returns data
getdirentries64(fd) returns 0 (EOF)
remove("dir/file")
getdirentries64(fd) returns ENOENT/EINVAL
Whether you get ENOENT or EINVAL depends on exactly what was
in the directory. It is deterministic, just data-dependent.
This only happens in small directories. A directory containing more data
than fits in a 4k getdirentries64 call will return EOF correctly.
(It's not clear if the criteria is that the directory be split across multiple
getdirentries64 calls or that it be split across multiple file system blocks.)
We could change package os to avoid the second read at EOF,
and maybe we should, but that's a bit involved.
For now, treat the EINVAL/ENOENT as EOF.
With this CL, all.bash passes on my MacBook Air running
OS X 10.10 (14A299l) and Xcode 6 beta 5 (6A279r).
I tried filing an issue with Apple using "Feedback Assistant", but it was
unable to send the report and lost it.
C program reproducing the issue, also at http://swtch.com/~rsc/readdirbug.c:
#include <stdio.h>
#include <dirent.h>
#include <unistd.h>
#include <sys/stat.h>
#include <stdlib.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
static void test(int);
int
main(void)
{
int fd, n;
DIR *dir;
struct dirent *dp;
struct stat st;
char buf[10000];
long basep;
int saw;
if(stat("/tmp/readdirbug", &st) >= 0) {
fprintf(stderr, "please rm -r /tmp/readdirbug and run again\n");
exit(1);
}
fprintf(stderr, "mkdir /tmp/readdirbug\n");
if(mkdir("/tmp/readdirbug", 0777) < 0) {
perror("mkdir /tmp/readdirbug");
exit(1);
}
fprintf(stderr, "create /tmp/readdirbug/file1\n");
if((fd = creat("/tmp/readdirbug/file1", 0666)) < 0) {
perror("create /tmp/readdirbug/file1");
exit(1);
}
close(fd);
test(0);
test(1);
fprintf(stderr, "ok - everything worked\n");
}
static void
test(int doremove)
{
DIR *dir;
struct dirent *dp;
int numeof;
fprintf(stderr, "\n");
fprintf(stderr, "opendir /tmp/readdirbug\n");
dir = opendir("/tmp/readdirbug");
if(dir == 0) {
perror("open /tmp/readdirbug");
exit(1);
}
numeof = 0;
for(;;) {
errno = 0;
dp = readdir(dir);
if(dp != 0) {
fprintf(stderr, "readdir: found %s\n", dp->d_name);
continue;
}
if(errno != 0) {
perror("readdir");
exit(1);
}
fprintf(stderr, "readdir: EOF\n");
if(++numeof == 3)
break;
if(doremove) {
fprintf(stderr, "rm /tmp/readdirbug/file1\n");
if(remove("/tmp/readdirbug/file1") < 0) {
perror("remove");
exit(1);
}
}
}
fprintf(stderr, "closedir\n");
closedir(dir);
}
Fixes#8423.
LGTM=bradfitz, r
R=golang-codereviews, bradfitz, dsymonds, dave, r
CC=golang-codereviews, iant
https://golang.org/cl/119530044
Current version of Getwd calls Stat that
calls Getwd therefore infinite recursion.
LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/119600043
The cmd/cc bundled with 9c has additional code compared to our cmd/cc, and
without those code, 9c couldn't handle switch statement where the expression
is not just a simple int32 or int64 variable (e.g. g->status or int8 variable).
All credit goes to rsc.
LGTM=rsc
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/125840043
The ast and printer don't care, and go/types can provide
a better error message.
This change requires an update to the tests for go/types
(go.tools repo). CL forthcoming.
Fixes#8493.
LGTM=adonovan
R=rsc, adonovan
CC=golang-codereviews
https://golang.org/cl/123010044
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
There are lots of internal synchronization in gob,
so it makes sense to have parallel benchmarks.
Also add a benchmark with slices and interfaces.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/115960043
This lets us have non-main packages like cmd/internal or cmd/nm/internal/whatever.
The src/pkg migration (see golang.org/s/go14mainrepo) will allow this
as a natural side effect. The explicit change here just allows use of the
effect a little sooner.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/117630043
To do in another CL: make cmd/objdump use cmd/internal/objfile too.
There is a package placement decision in this CL:
cmd/internal/objfile instead of internal/objfile.
I chose to put internal under cmd to make clear (and enforce)
that no standard library packages should use this
(it's a bit dependency-heavy).
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/123910043
To reduce delta for the upcoming liblink CL.
Just code movement, no semantic changes.
LGTM=rsc
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/124830043
Eliminating use of this extension makes it easier to port the Go runtime
to other compilers. This CL also disables the extension in cc to prevent
accidental use.
LGTM=rsc, khr
R=rsc, aram, khr, dvyukov
CC=axwalk, golang-codereviews
https://golang.org/cl/106790044
This makes os.Getwd mimic C getwd on OS X,
and possibly other systems. The change on OS X
was a regression from 1.2 to 1.3.
Fixes#8400.
LGTM=bradfitz
R=iant, bradfitz
CC=golang-codereviews
https://golang.org/cl/118970043
FlagNoGC is unused now.
FlagNoInvokeGC is unneeded as we don't invoke GC
on g0 and when holding locks anyway.
mal/malloc have very few uses and you never remember
the exact set of flags they use and the difference between them.
Moreover, eventually we need to give exact types to all allocations,
something what mal/malloc do not support.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/117580043
Shrinkstack does not touch normal heap anymore,
so we can shink stacks concurrently with marking.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, khr, rlh, rsc
https://golang.org/cl/122130043
After CL 117670045, cmd/dist will expect to have a cmd/9g directory.
LGTM=rsc, dave
R=rsc, iant, dave
CC=golang-codereviews
https://golang.org/cl/126780043
No modifications other than adding copyright header to each file, and
concatenating several cmd/9l files together to form the liblink files.
LGTM=rsc
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/123840043
Among other things, this allows users to match the decoded
pieces with the original XML, which can be necessary for
implementing standards like XML signatures.
Fixes#8484.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/122960043
This fixes two problems: x/internal/y/z was using parent = x/internal/y instead of x,
and hasPathPrefix only looks at /, not \ for Windows.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/121280045
Introduce the mFunction type to represent an mcall/onM-able function.
Name such functions using _m.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/121320043
Hashing on the bytes instead of the words does
a (much) better job of using all the bits, so that
maps of floats have linear performance.
LGTM=khr
R=golang-codereviews, khr
CC=adonovan, golang-codereviews
https://golang.org/cl/126720044
The implementation 'return 0' results in too many collisions.
LGTM=khr
R=golang-codereviews, adonovan, khr
CC=golang-codereviews, iant, khr, r
https://golang.org/cl/125720044
hg insists that we not list explicit files for a merge.
for benefit of other tools reading logs, include branch prefix
at start of every commit message.
LGTM=minux
R=minux
CC=golang-codereviews
https://golang.org/cl/124780044
1) The arrayindexof lookup function is O(n). Replace with O(1) lookups.
2) The checkptxt function is O(n²) and is purely for debugging.
Only run when the debugging flags are turned on.
3) Iterating over sparse bitmaps can be done faster word by word.
Introduce and use bvnext for that.
Run times before and after, on my 2.5 GHz Core i5 MacBook Pro.
x.go 9.48 0.84 issue 8259
x100.go 0.01 0.01 issue 8354
x1000.go 0.10 0.10
x2000.go 0.62 0.19
x3000.go 1.33 0.34
x4000.go 2.29 0.49
x5000.go 3.89 0.67
x6000.go 5.00 0.90
x7000.go 6.70 1.13
x8000.go 9.44 1.38
x9000.go 11.23 1.87
x10000.go 13.78 2.09
Fixes#8259.
Fixes#8354.
LGTM=iant, r
R=golang-codereviews, iant, r
CC=golang-codereviews
https://golang.org/cl/125720043
The linker currently produces the DWARF 3 DW_TAG_unspecified_type tag, however the Reader in debug/dwarf will panic whenever that tag is encountered.
Fixes#8437.
LGTM=rsc
R=golang-codereviews, bradfitz, iant, rsc
CC=golang-codereviews
https://golang.org/cl/117280043
This is an experiment. See mail on golang-dev
(subject: "an experiment: development branches").
LGTM=minux
R=minux
CC=golang-codereviews
https://golang.org/cl/117660043
It can happen legitimately if a profiling signal arrives at just the wrong moment.
It's harmless.
Fixes#8153.
LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews, iant, r
https://golang.org/cl/118670043
Full spans can't be passed to UncacheSpan since we get rid of free.
LGTM=rsc
R=golang-codereviews
CC=golang-codereviews, khr, rsc
https://golang.org/cl/119490044
Since CL 115060044, mkanames declares an empty
array in anames8.c and anames6.c, which is not
valid for the Plan 9 compiler.
char* cnames8[] = {
};
This change makes mkanames not declaring the
cnames array when no C_ constants are found.
LGTM=iant
R=minux, iant
CC=golang-codereviews
https://golang.org/cl/117680043
The helps certain diagnostics and also removed duplicated enums as a side effect.
LGTM=dave, rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/115060044
Encode MOV $0, %ax as XOR %eax, %eax instead of
XOR %rax, %rax. If an operand register does not
need REX.w bit (i.e. not one of R8-R15), it is
encoded in 2 bytes instead of 3 bytes.
LGTM=rsc
R=golang-codereviews, gobot, rsc
CC=golang-codereviews
https://golang.org/cl/115580044
Instead of immediately completing pointer type mappings, add them to
a queue to allow them to be completed later. This fixes issues caused
by Type() returning arbitrary in-progress type mappings.
Fixes#8368.
Fixes#8441.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/122850043
Instead of including <sys/types.h> to get size_t, instead include
the ISO C standard <stddef.h> header, which defines fewer additional
types at risk of colliding with the user code. In particular, this
prevents collisions between <sys/types.h>'s userspace definitions with
the kernel definitions needed by defs_linux.go.
Also, -cdefs mode uses #pragma pack, so we can keep misaligned fields.
Fixes#8477.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/120610043
Before fixing issue 6579 this CL separates DNS transport from
DNS message interaction to make it easier to add builtin DNS
resolver control logic.
Update #6579
LGTM=alex, kevlar
R=golang-codereviews, alex, gobot, iant, minux, kevlar
CC=golang-codereviews
https://golang.org/cl/101220044
Update #6677
When a struct contains an anonymous union, use the type and
name of the first field in the union.
This should make the glibc <sys/resource.h> file work; in that
file struct rusage has fields like
__extension__ union
{
long int ru_maxrss;
__syscall_slong_t __ru_maxrss_word;
};
in which the field that matters is ru_maxrss and
__ru_maxrss_word just exists to advance to the next field on
systems where the kernel uses long long fields but userspace
expects long fields.
LGTM=mikioh.mikioh
R=golang-codereviews, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/106260044
We call scanblock for lots of small root pieces
e.g. for every stack frame args and locals area.
Every scanblock invocation calls getempty/putempty,
which accesses lock-free stack shared among all worker threads.
One-element local cache allows most scanblock calls
to proceed without accessing the shared stack.
LGTM=rsc
R=golang-codereviews, rlh
CC=golang-codereviews, khr, rsc
https://golang.org/cl/121250043
If the process exits before the spawned goroutine
completes, it'll miss the data race.
LGTM=bradfitz
R=bradfitz
CC=dvyukov, golang-codereviews
https://golang.org/cl/122120043
Camlistore uses this pattern to do streaming writes, as do
others I imagine, and it was broken by the lazy boundary
change.
LGTM=dvyukov, ruiu
R=ruiu, dvyukov
CC=golang-codereviews, mathieu.lonjaret
https://golang.org/cl/116690043
Breaks Camlistore by introducing a datarace. See comments on
https://golang.org/cl/95760043/ for details.
I'll add a new test to lock-in the current behavior in a
subsequent CL.
I don't think Camlistore is particularly unique here: it's doing
the obvious thing to stream a multipart body to a server
using a goroutine feeding the multipart writer.
««« original CL description
mime/multipart: delay reading random source
If a user sets his/her own boundary string with SetBoundary,
we don't need to call randomBoundary at all.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/95760043
»»»
LGTM=ruiu
R=ruiu
CC=golang-codereviews, mathieu.lonjaret
https://golang.org/cl/117600043
We have an autogenerated version in zruntime_defs.
I am not sure what are the consequences as gdb never printed any values for me.
But it looks unnecessary to manually duplicate it.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews, iant, khr
https://golang.org/cl/115660043
Technically a language change, this cleanup is a completely
backward compatible change that brings the boolean results
of comma-ok expressions in line with the boolean results of
comparisons: they are now all untyped booleans.
The implementation effort should be minimal (less than a
handfull lines of code, depending how well factored the
implementation of comma-ok expressions is).
Fixes#8189.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/112320045
For consistency with other code, as that was the only use of
memcopy outside of alg.goc.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/122030044
The gccgo version of USED only accepts a single variable, so
this simplifies merging.
LGTM=minux, dave
R=golang-codereviews, minux, dave
CC=golang-codereviews
https://golang.org/cl/115630043
Popular tools both add incorrect trailing zeroes to the zip
extras, and popular tools accept trailing zeros. We seemed to
be the only ones being strict here. Stop being strict. :(
Fixes#8186
LGTM=ruiu, adg, dave
R=adg, ruiu, dave
CC=frohrweck, golang-codereviews
https://golang.org/cl/117550044
This CL removes sockaddrToAddr functions from socket creation
operations to avoid the bug like issue 7183.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/105100046
Avoid some pressure on the global mutex by lifting the call to userType
out of the closure.
TOTH to Matt Harden.
LGTM=crawshaw, ruiu
R=golang-codereviews, crawshaw, ruiu
CC=golang-codereviews
https://golang.org/cl/117520043
A good cleanup anyway, and it makes some room for an additional
field needed for issue 8412.
Update #8412
LGTM=iant
R=iant, khr
CC=golang-codereviews
https://golang.org/cl/112700043
6a and 8a rearrange memmove such that the fallthrough from move_1or2 to move_0 ends up being a JMP to a RET. Insert an explicit RET to prevent such silliness.
Do the same for memclr as prophylaxis.
benchmark old ns/op new ns/op delta
BenchmarkMemmove1 4.59 4.13 -10.02%
BenchmarkMemmove2 4.58 4.13 -9.83%
LGTM=khr
R=golang-codereviews, dvyukov, minux, ruiu, bradfitz, khr
CC=golang-codereviews
https://golang.org/cl/120930043
Create proper closures so hash functions can be called
directly from Go. Rearrange calling convention so return
value is directly accessible.
LGTM=dvyukov
R=golang-codereviews, dvyukov, dave, khr
CC=golang-codereviews
https://golang.org/cl/119360043
Several reasons:
1. Significantly simplifies runtime.
2. This code proved to be buggy.
3. Free is incompatible with bump-the-pointer allocation.
4. We want to write runtime in Go, Go does not have free.
5. Too much code to free env strings on startup.
LGTM=khr
R=golang-codereviews, josharian, tracey.brendan, khr
CC=bradfitz, golang-codereviews, r, rlh, rsc
https://golang.org/cl/116390043
Stand-alone this test is fine. Run together with
others, however, the stack used can actually go
negative because other tests are freeing stack
during its execution.
This behavior is new with the new stack allocator.
The old allocator never returned (min-sized) stacks.
This test is fairly poor - it needs to run in
isolation to be accurate. Maybe we should delete it.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/119330044
The DISPATCH and CALLFN macro definitions depend on an inconsistency
between the internal cpp mini-implementation and the language proper in
whether center-dot is an identifier character. The macro depends on it not
being an identifier character, but the resulting code depends on it being one.
Remove the dependence on the inconsistency by placing the center-dot into
the macro invocation rather that the body.
No semantic change. This is just renaming macro arguments.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/119320043
This change introduces gomallocgc, a Go clone of mallocgc.
Only a few uses have been moved over, so there are still
lots of uses from C. Many of these C uses will be moved
over to Go (e.g. in slice.goc), but probably not all.
What should remain of C's mallocgc is an open question.
LGTM=rsc, dvyukov
R=rsc, khr, dave, bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/108840046
If a user sets his/her own boundary string with SetBoundary,
we don't need to call randomBoundary at all.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/95760043
preparing for the syscall package freeze.
««« original CL description
syscall: consolidate, simplify socket options for Unix-like systems
Also exposes common socket option functions on Solaris.
Update #7174
Update #7175
LGTM=aram
R=golang-codereviews, aram
CC=golang-codereviews
https://golang.org/cl/107280044
»»»
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/121880043
preparing for the syscall package freeze.
««« original CL description
syscall: regenerate z-files for darwin
Updates z-files from 10.7 kernel-based to 10.9 kernel-based.
LGTM=iant
R=golang-codereviews, bradfitz, iant
CC=golang-codereviews
https://golang.org/cl/102610045
»»»
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/114530044
Delete an erroneously doubled name in both files. Once is enough.
LGTM=dave
R=golang-codereviews, dave
CC=golang-codereviews
https://golang.org/cl/118420043
This is meant to share my progress on Issue 8275, if it's useful to you. I'm not familiar with the formatter's internals, so this change is likely naive.
Change these calls to measure width in runes not bytes:
fmt.Printf("(%5q)\n", '§')
fmt.Printf("(%3c)\n", '§')
Fixes#8275.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/104320043
On Linux, adding a socket descriptor to epoll instance before getting
the EINPROGRESS return value from connect system call could be a root
cause of spurious on-connect events.
See golang.org/issue/8276, golang.org/issue/8426 for further information.
All credit to Jason Eggleston <jason@eggnet.com>
Fixes#8276.
Fixes#8426.
LGTM=dvyukov
R=dvyukov, golang-codereviews, adg, dave, iant, alex.brainman
CC=golang-codereviews
https://golang.org/cl/120820043
Implement the design described in:
https://docs.google.com/document/d/1v4Oqa0WwHunqlb8C3ObL_uNQw3DfSY-ztoA-4wWbKcg/pub
Summary of the changes:
GC uses "2-bits per word" pointer type info embed directly into bitmap.
Scanning of stacks/data/heap is unified.
The old spans types go away.
Compiler generates "sparse" 4-bits type info for GC (directly for GC bitmap).
Linker generates "dense" 2-bits type info for data/bss (the same as stacks use).
Summary of results:
-1680 lines of code total (-1000+ in mgc0.c only)
-25% memory consumption
-3-7% binary size
-15% GC pause reduction
-7% run time reduction
LGTM=khr
R=golang-codereviews, rsc, christoph, khr
CC=golang-codereviews, rlh
https://golang.org/cl/106260045
Because the reference time is the reference time but beginners seem
to think otherwise, make it clearer you can't choose the reference time.
LGTM=josharian, dave
R=golang-codereviews, josharian, dave
CC=golang-codereviews
https://golang.org/cl/117250044
This change causes a TLS client and server to verify that received
elliptic curve points are on the expected curve. This isn't actually
necessary in the Go TLS stack, but Watson Ladd has convinced me that
it's worthwhile because it's pretty cheap and it removes the
possibility that some change in the future (e.g. tls-unique) will
depend on it without the author checking that precondition.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/115290046
ASN.1 elements can be optional, and can have a default value.
Traditionally, Go has omitted elements that are optional and that have
the zero value. I believe that's a bug (see [1]).
This change causes an optional element with a default value to only be
omitted when it has that default value. The previous behaviour of
omitting optional, zero elements with no default is retained because
it's used quite a lot and will break things if changed.
[1] https://groups.google.com/d/msg/Golang-nuts/9Ss6o9CW-Yo/KL_V7hFlyOAJFixes#7780.
R=bradfitz
LGTM=bradfitz
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews, r
https://golang.org/cl/86960045
While we're here, make it lookup the tlsfallback symbol only once.
LGTM=crawshaw
R=golang-codereviews, crawshaw, dave
CC=golang-codereviews
https://golang.org/cl/107430044
selv is created with temp() which calls tempname, which marks
the new n with EscNever, so there is no need to explicitly set
EscNone on the select descriptor.
Fixes#8396.
LGTM=dvyukov
R=golang-codereviews, dave, dvyukov
CC=golang-codereviews
https://golang.org/cl/112520043
golang.org now serves HTTPS with a valid cert, so it's reasonable
that users should click through to the HTTPS versions of *.golang.org
and other known sites.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/112650043
Sweepone may be running while a new span is allocating. It
must not see the state updated while the sweepgen is unset.
Fixes#8399
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews
https://golang.org/cl/118050043
Following CL 68150047, the goos and goarch
variables are not currently set when the GOOS
and GOARCH environment variables are not set.
This made the content of the build tag to be
ignored in this case.
This CL sets goos and goarch to runtime.GOOS
and runtime.GOARCH when the GOOS and GOARCH
environments variables are not set.
LGTM=aram, bradfitz
R=golang-codereviews, aram, gobot, rsc, dave, bradfitz
CC=golang-codereviews, rsc
https://golang.org/cl/112490043
This is bad for 2 reasons:
1. if the code under lock ever grows stack,
it will deadlock as stack growing acquires mheap lock.
2. It currently deadlocks with SetCPUProfileRate:
scavenger locks mheap, receives prof signal and tries to lock prof lock;
meanwhile SetCPUProfileRate locks prof lock and tries to grow stack
(presumably in runtime.unlock->futexwakeup). Boom.
Let's assume that it
Fixes#8407.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews, khr
https://golang.org/cl/112640043
With cl/112640043 TestCgoDeadlockCrash episodically print:
unexpected return pc for runtime.newstackcall
After adding debug output I see the following trace:
runtime: unexpected return pc for runtime.newstackcall called from 0xc208011b00
runtime.throw(0x414da86)
src/pkg/runtime/panic.c:523 +0x77
runtime.gentraceback(0x40165fc, 0xba440c28, 0x0, 0xc208d15200, 0xc200000000, 0xc208ddfd20, 0x20, 0x0, 0x0, 0x300)
src/pkg/runtime/traceback_x86.c:185 +0xca4
runtime.callers(0x1, 0xc208ddfd20, 0x20)
src/pkg/runtime/traceback_x86.c:438 +0x98
mcommoninit(0xc208ddfc00)
src/pkg/runtime/proc.c:369 +0x5c
runtime.allocm(0xc208052000)
src/pkg/runtime/proc.c:686 +0xa6
newm(0x4017850, 0xc208052000)
src/pkg/runtime/proc.c:933 +0x27
startm(0xc208052000, 0x100000001)
src/pkg/runtime/proc.c:1011 +0xba
wakep()
src/pkg/runtime/proc.c:1071 +0x57
resetspinning()
src/pkg/runtime/proc.c:1297 +0xa1
schedule()
src/pkg/runtime/proc.c:1366 +0x14b
runtime.gosched0(0xc20808e240)
src/pkg/runtime/proc.c:1465 +0x5b
runtime.newstack()
src/pkg/runtime/stack.c:891 +0x44d
runtime: unexpected return pc for runtime.newstackcall called from 0xc208011b00
runtime.newstackcall(0x4000cbd, 0x4000b80)
src/pkg/runtime/asm_amd64.s:278 +0x6f
I suspect that it can happen on any stack split.
So don't unwind g0 stack.
Also, that comment is lying -- we can traceback w/o mcache,
CPU profiler does that.
LGTM=rsc
R=golang-codereviews
CC=golang-codereviews, khr, rsc
https://golang.org/cl/120040043
There are fields in the Addr that do not matter for the
purpose of deciding that the same word is already
in the current literal pool. Copy only the fields that
do matter.
This came up when comparing against the Go version
because the way it is invoked doesn't copy a few fields
(like node) that are never directly used by liblink itself.
Also remove a stray print that is not well-defined in
the new liblink. (Cannot use %D outside of %P, because
%D needs the outer Prog*.)
LGTM=minux
R=minux
CC=golang-codereviews
https://golang.org/cl/119000043
This matches Go's fmt.Printf instead of ANSI C's dumb rules.
It makes the -S output from C liblink match Go's liblink.
LGTM=minux
R=minux
CC=golang-codereviews
https://golang.org/cl/112600043
They do not, but pretend that they do.
The immediate need is that it breaks the new GC because
these are weird symbols as if with pointers but not necessary
pointer aligned.
LGTM=rsc
R=golang-codereviews, dave, josharian, khr, rsc
CC=golang-codereviews, iant, khr, rlh
https://golang.org/cl/116060043
I've found this very useful for generating
good test case lists for -short mode for
the disassemblers.
Fixes#7959.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/98150043
Currently they are scanned conservatively.
But there is no reason to scan them. C world must not contain
pointers into Go heap. Moreover, we don't have enough information
to emit write barriers nor update pointers there in future.
The immediate need is that it breaks the new GC because
these are weird symbols as if with pointers but not necessary
pointer aligned.
LGTM=rsc
R=golang-codereviews, rlh, rsc
CC=golang-codereviews, iant, khr
https://golang.org/cl/117000043
In the runtime, we want to control where allocations happen.
In particular, we don't want the code implementing malloc to
itself trigger a malloc. This change prevents the compiler
from inserting mallocs on our behalf (due to escaping declarations).
This check does not trigger on the current runtime code.
Note: Composite literals are still allowed.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/105280047
So we can tell from a binary which version of
Go built it.
LGTM=minux, rsc
R=golang-codereviews, minux, khr, rsc, dave
CC=golang-codereviews
https://golang.org/cl/117040043
This is more useful than panicking, since otherwise every caller needs
to do the length check before calling; some will forget, and have a
potential submarine crasher as a result. Other implementations of this
functionality do a length check.
This is backward compatible, except if someone has written code that
relies on this panicking with different length args. However, that was
not the case before Go 1.3 either.
Updates #7304.
LGTM=agl
R=agl, minux, hanwen
CC=golang-codereviews
https://golang.org/cl/118750043
In both cases we lie to malloc about the actual size that we need.
In panic we ask for less memory than we are going to use.
In slice we ask for more memory than we are going to use
(potentially asking for a fractional number of elements).
This breaks the new GC.
LGTM=khr
R=golang-codereviews, dave, khr
CC=golang-codereviews, rsc
https://golang.org/cl/116940043
Rewrite gotos that violate Go's stricter rules.
Use uchar* instead of char* in a few places that aren't strings.
Remove dead opcross code from asm5.c.
Declare regstr (in both list6 and list8) static.
LGTM=minux, dave
R=minux, dave
CC=golang-codereviews
https://golang.org/cl/113230043
Even though pointers are 4 bytes the stack frame should be kept
a multiple of 8 bytes so that return addresses pushed on the stack
are properly aligned.
Fixes#8379.
LGTM=dvyukov, minux
R=minux, bradfitz, dvyukov, dave
CC=golang-codereviews
https://golang.org/cl/115840048
We might want to add a go/build.IsInternal(pkg string) bool
later, but this works for now.
LGTM=dave, rsc
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/113300044
These correspond to 2 and 3 word fat copies/clears on 8g, which dominate usage in the stdlib. (70% of copies and 46% of clears are for 2 or 3 words.) I missed these in CL 111350043, which added 2 and 3 word benchmarks for 6g. A follow-up CL will optimize these cases.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/115160043
I'm improving gccgo's detection of variables that are only set
but not used, and it triggers additional errors on this code.
The new gccgo errors are correct; gc seems to suppress them
due to the other, expected, errors. This change uses the
variables so that no compiler will complain.
gccgo change is https://golang.org/cl/119920043 .
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/116050043
benchmark old ns/op new ns/op delta
BenchmarkSelectUncontended 220 165 -25.00%
BenchmarkSelectContended 209 161 -22.97%
BenchmarkSelectProdCons 1042 904 -13.24%
But more importantly this change will allow
to get rid of free function in runtime.
Fixes#6494.
LGTM=rsc, khr
R=golang-codereviews, rsc, dominik.honnef, khr
CC=golang-codereviews, remyoudompheng
https://golang.org/cl/107670043
This is a temporary change to see how far the
builder gets when it times out.
LGTM=aram, 0intro
R=0intro, aram
CC=golang-codereviews, mischief
https://golang.org/cl/111400043
Fix virtual address of the start of the text segment
on amd64 Plan 9.
This issue has been partially fixed in cmd/add2line,
as part of CL 106460044, but we forgot to report the
change to cmd/objdump.
In the meantime, we also fixed the textStart address
in both cmd/add2line and cmd/objdump.
LGTM=aram, ality, mischief
R=rsc, mischief, aram, ality
CC=golang-codereviews, jas
https://golang.org/cl/117920043
Hook pre-commit runs before 'hg commit' command whereas hook precommit runs
after the user has entered commit message.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/106320043
The CopyFat benchmarks were changed in CL 92760044. See CL 111350043 for discussion.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/116000043
These benchmarks are important for performance. When compiling the stdlib:
* 77.1% of the calls to sgen (copyfat) are for 16 bytes; another 8.7% are for 24 bytes. (The next most common is 32 bytes, at 5.7%.)
* Over half the calls to clearfat are for 16 or 24 bytes.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews
https://golang.org/cl/111350043
Ken's standalone file server and its derivatives, like cwfs, return
error strings different from fossil when the user opens non-existent
files.
LGTM=aram, 0intro, r
R=0intro, aram, r
CC=golang-codereviews, ken
https://golang.org/cl/112420045
Also, fix a write check in writeBuf and make some bounds checks simpler.
LGTM=gri
R=golang-codereviews, adg, gri, r, minux
CC=golang-codereviews
https://golang.org/cl/113060043
updatememstats is called on both the m and g stacks.
Call into flushallmcaches correctly. flushallmcaches
can only run on the M stack.
This is somewhat temporary. once ReadMemStats is in
Go we can have all of this code M-only.
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews
https://golang.org/cl/116880043
Encoder compilation must be enc-independent,
because the resulting program is reused across
different encoders.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/115860043
Breaks build for FreeBSD. Probably clang related?
««« original CL description
cmd/cgo: disable inappropriate warnings when the gcc struct is empty
package main
//#cgo CFLAGS: -Wall
//void test() {}
import "C"
func main() {
C.test()
}
This code will cause gcc issuing warnings about unused variable.
This commit use offset of the second return value of
Packages.structType to detect whether the gcc struct is empty,
and if it's directly invoke the C function instead of writing an
unused code.
LGTM=dave, minux
R=golang-codereviews, iant, minux, dave
CC=golang-codereviews
https://golang.org/cl/109640045
»»»
TBR=dfc
R=dave
CC=golang-codereviews
https://golang.org/cl/114990044
package main
//#cgo CFLAGS: -Wall
//void test() {}
import "C"
func main() {
C.test()
}
This code will cause gcc issuing warnings about unused variable.
This commit use offset of the second return value of
Packages.structType to detect whether the gcc struct is empty,
and if it's directly invoke the C function instead of writing an
unused code.
LGTM=dave, minux
R=golang-codereviews, iant, minux, dave
CC=golang-codereviews
https://golang.org/cl/109640045
redo stack allocation. This is mostly the same as
the original CL with a few bug fixes.
1. add racemalloc() for stack allocations
2. fix poolalloc/poolfree to terminate free lists correctly.
3. adjust span ref count correctly.
4. don't use cache for sizes >= StackCacheSize.
Should fix bugs and memory leaks in original changelist.
««« original CL description
undo CL 104200047 / 318b04f28372
Breaks windows and race detector.
TBR=rsc
««« original CL description
runtime: stack allocator, separate from mallocgc
In order to move malloc to Go, we need to have a
separate stack allocator. If we run out of stack
during malloc, malloc will not be available
to allocate a new stack.
Stacks are the last remaining FlagNoGC objects in the
GC heap. Once they are out, we can get rid of the
distinction between the allocated/blockboundary bits.
(This will be in a separate change.)
Fixes#7468Fixes#7424
LGTM=rsc, dvyukov
R=golang-codereviews, dvyukov, khr, dave, rsc
CC=golang-codereviews
https://golang.org/cl/104200047
»»»
TBR=rsc
CC=golang-codereviews
https://golang.org/cl/101570044
»»»
LGTM=dvyukov
R=dvyukov, dave, khr, alex.brainman
CC=golang-codereviews
https://golang.org/cl/112240044
Resolves TODO for not walking all goroutines in NumGoroutines.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/107290044
1. Add select on sync channels benchmark.
2. Make channels in BenchmarkSelectNonblock shared.
With GOMAXPROCS=1 it is the same, but with GOMAXPROCS>1
it becomes a more interesting benchmark.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews
https://golang.org/cl/115780043
Previously we had a bitmap to check whether or not a byte
appears in a string should be replaced. But we don't actually
need a separate bitmap for that purpose. Removing the bitmap
makes the code simpler.
LGTM=dave, iant, nigeltao
R=golang-codereviews, dave, gobot, nigeltao, iant, bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/110100043
Fixes#5750.
https://code.google.com/p/go/issues/detail?id=5750
os: Separate windows from posix. Implement windows support.
path/filepath: Use the same implementation as other platforms
syscall: Add/rework new APIs for Windows
LGTM=alex.brainman
R=golang-codereviews, alex.brainman, gobot, rsc, minux
CC=golang-codereviews
https://golang.org/cl/86160044
"archive/tar: reuse temporary buffer in writeHeader" introduced a
change which was supposed to help lower the number of allocations from
512 bytes for every call to writeHeader. This change broke the writing
of PAX headers.
writeHeader calls writePAXHeader and writePAXHeader calls writeHeader
again. writeHeader will end up writing the PAX header twice.
example broken header:
PaxHeaders.4007/NetLock_Arany_=Class_Gold=_Ftanstvny.crt0000000000000000000000000000007112301216634021512 xustar0000000000000000
PaxHeaders.4007/NetLock_Arany_=Class_Gold=_Ftanstvny.crt0000000000000000000000000000007112301216634021512 xustar0000000000000000
example correct header:
PaxHeaders.4290/NetLock_Arany_=Class_Gold=_Ftanstvny.crt0000000000000000000000000000007112301216634021516 xustar0000000000000000
0100644000000000000000000000270412301216634007250 0ustar0000000000000000
This commit adds a dedicated buffer for pax headers to the Writer
struct. This change increases the size of the struct by 512 bytes, but
allows tar/writer to avoid allocating 512 bytes for all written
headers and it avoids allocating 512 more bytes for pax headers.
LGTM=dsymonds
R=dsymonds, dave, iant
CC=golang-codereviews
https://golang.org/cl/110480043
The garbage collector and stack scans are good enough now.
Fixes#7446.
LGTM=r
R=r, dvyukov
CC=golang-codereviews, mdempsky, mtj
https://golang.org/cl/112870046
As written, the ! applies before the &1.
This would crash writing out missing pcdata tables
if we ever used non-contiguous IDs in a function.
We don't, but fix anyway.
LGTM=iant, minux
R=minux, iant
CC=golang-codereviews
https://golang.org/cl/117810047
DWARF says only one is necessary.
The count is preferable because it admits 0-length arrays.
Update debug/dwarf to handle either form.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/111230044
They can be large, so use a varint encoding rather than only one byte.
LGTM=iant, rsc
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/113180043
The issue is discovered during testing of a change to runtime.
Even if it is unlikely to happen, the comment can safe an hour
next person who hits it.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/116790043
I don't see how it can lead to bad things today.
But it's better to kill it before it does.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/111130045
Make CanBackquote(invalid UTF-8) return false.
Also add two test which show that CanBackquote reports
true for strings containing a BOM.
Fixes#7572.
LGTM=r
R=golang-codereviews, bradfitz, r
CC=golang-codereviews
https://golang.org/cl/111780045
This CL adds 'dropg', which is called to drop the association
between m and its current goroutine, and it makes schedule
handle locked goroutines correctly, instead of requiring all
callers of schedule to do that.
The effect is that if you want to take over an m for, say,
garbage collection work while still allowing the current g
to run on some other m, you can do an mcall to a function
that is:
// dissociate gp
dropg();
gp->status = Gwaiting; // for ready
// put gp on run queue for others to find
runtime·ready(gp);
/* ... do other work here ... */
// done with m, let it run goroutines again
schedule();
Before this CL, the dropg() body had to be written explicitly,
and the check for lockedg before schedule had to be
written explicitly too, both of which make the code a bit
more fragile than it needs to be.
LGTM=iant
R=dvyukov, iant
CC=golang-codereviews, rlh
https://golang.org/cl/113110043
This is a fully backward-compatible language change.
There are not a lot of cases in the std library, but
there are some. Arguably this makes the syntax a bit
more regular - any trailing index variable that is _
can be left away, and there's some analogy to type
switches where the temporary can be left away.
Implementation-wise the change should be trivial as
it can be done completely syntactically. For instance,
the respective change in go/parser is a dozen lines
(see https://golang.org/cl/112970044 ).
Fixes#6102.
LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/104680043
This variable allows users to select the compiler when using the
gccgo toolchain.
LGTM=rsc
R=rsc, iant, minux, aram
CC=axwalk, golang-codereviews
https://golang.org/cl/106700044
warning: /usr/go/src/liblink/asm5.c:720 set and not used: m
warning: /usr/go/src/liblink/asm5.c:807 set and not used: c
LGTM=minux
R=minux
CC=golang-codereviews
https://golang.org/cl/108570043
The debug/dwarf package cannot parse the format generated here,
but the format can be changed so it does.
After this edit, tweaking the expression defining the offset
of a struct field, the dwarf package can parse the tables (again?).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/105710043
Fixes#6293.
Image "testdata/benchRGB-interlace.png" was generated by opening "testdata/benchRGB.png" in the editor Gimp and saving it with interlacing enabled.
Benchmark:
BenchmarkDecodeRGB 500 7014194 ns/op 37.37 MB/s
ok pkg/image/png 4.657s
BenchmarkDecodeInterlacing 100 10623241 ns/op 24.68 MB/s
ok pkg/image/png 1.339s
LGTM=nigeltao
R=nigeltao, andybons, matrixik
CC=golang-codereviews
https://golang.org/cl/102130044
(This is a patch from the pkgsrc Go package.)
LGTM=iant
R=golang-codereviews, iant, joerg.sonnenberger, dave
CC=golang-codereviews, joerg
https://golang.org/cl/108340043
Added a complement to (*File).Symbols for the dynamic symbol table.
Would be useful, for instance, if seraching for certain shared objects
compatible with certain libraries (for instance, LADSPA requires an
exported symbol "ladspa_descriptor").
Added a variable ErrNoSymbols that canonicalizes a return from
(*File).Symbols and (*File).DyanmicSymbols if the file has no symbols.
Added tests for both (*File).Symbols and (*File).DynamicSymbols;
there was never a test for (*File).Symbols at all. A small C program using
libelf, included in the test data, was used to produce the golden
symbols to compare against.
As part of the requirements for testing, (*File).Symbols and (*File).DynamicSymbols now document the order in which the symbol tables are returned (in the order the symbols appear in the file).
All tests currently pass.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/107530043
Also detect GOARCH automatically based on `uname -m`.
LGTM=crawshaw, dave, rsc
R=rsc, iant, crawshaw, dave
CC=golang-codereviews
https://golang.org/cl/111780043
Found using the vet check in CL 106370045.
This is a second attempt at CL 101670044, which omitted the deps_test change.
This adds dependencies to net/rpc:
encoding
encoding/base64
encoding/json
html
unicode/utf16
The obvious correctness and security warrants the additional dependencies.
LGTM=rsc
R=r, minux, rsc, adg
CC=golang-codereviews
https://golang.org/cl/110890043
When we've switched to 8K pages,
heap started to grow by 128K instead of 64K,
because it was implicitly assuming that pages are 4K.
Fix that and make the code more robust.
LGTM=khr
R=golang-codereviews, dave, khr
CC=golang-codereviews, rsc
https://golang.org/cl/106450044
Also remove arch-specific Go files in the Plan 9 syscall package
LGTM=0intro
R=0intro, dave
CC=ality, golang-codereviews, jas, mischief, rsc
https://golang.org/cl/112720043
size instead of abusing text symbol
cmd/addr2line needs to know the virtual address of the start
of the text segment (load address plus header size). For
this, it used the text symbol added by the linker. This is
wrong on amd64. Header size is 40 bytes, not 32 like on 386
and arm. Function alignment is 16 bytes causing text to be
at 0x200030.
debug/plan9obj now exports both the load address and the
header size; cmd/addr2line uses this new information and
doesn't rely on text anymore.
LGTM=0intro
R=0intro, gobot, ality
CC=ality, golang-codereviews, jas, mischief
https://golang.org/cl/106460044
NetlinkRIB is currently allocating a page sized slice of bytes in a
for loop and it's also calling Getpagesize() in the same for loop.
This CL changes NetlinkRIB to preallocate the page sized slice of
bytes before reaching the for loop. This reduces memory allocations
and lowers the number of calls to Getpagesize() to 1 per NetlinkRIB
call.
This CL reduces the allocated memory from 141.5 MB down to 52 MB in
a test.
LGTM=crawshaw, dave
R=dave, dsymonds, crawshaw
CC=bradfitz, dsymonds, golang-codereviews
https://golang.org/cl/110920043
Fixes#8165.
After this change, the panic is replaced by a message:
$ go build -o out ...doesntexist
warning: "...doesntexist" matched no packages
no packages to build
The motivation to return 1 exit error code is to allow -o flag
to be used to guarantee that the output binary is written to
when exit status is 0. If someone uses an import path pattern
to specify a single package and suddenly that matches no packages,
it's better to return exit code 1 instead of silently doing nothing.
This is consistent with the case when -o flag is given and multiple
packages are matched.
It's also somewhat consistent with the current behavior with the
panic, except that gave return code 2. But it's similar in
that it's also non-zero (indicating failure).
I've changed the language to be similar to output of go test
when an import path pattern matches no packages (it also has a return status of
1):
$ go test ...doesntexist
warning: "...doesntexist" matched no packages
no packages to test
LGTM=adg
R=golang-codereviews, josharian, gobot, adg
CC=golang-codereviews
https://golang.org/cl/107140043
Maxstring is not updated in the new string routines,
this makes runtime think that long strings are bogus.
Fixes#8339.
LGTM=crawshaw, iant
R=golang-codereviews, crawshaw, iant
CC=golang-codereviews, khr, rsc
https://golang.org/cl/110930043
Broke build; missing deps_test change. Will re-send the original with the appropriate fix.
««« original CL description
net/rpc: use html/template to render html
Found using the vet check in CL 106370045.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/101670044
»»»
TBR=r
CC=golang-codereviews
https://golang.org/cl/110880044
The code generating the .debug_frame section emits pairs of "advance PC",
"set SP offset" pseudo-instructions. Before the fix, the PC advance comes
out before the SP setting, which means the emitted offset for a block is
actually the value at the end of the block, which is incorrect for the
block itself.
The easiest way to fix this problem is to emit the SP offset before the
PC advance.
One delicate point: the last instruction to come out is now an
"advance PC", which means that if there are padding intsructions after
the final RET, they will appear to have a non-zero offset. This is odd
but harmless because there is no legal way to have a PC in that range,
or to put it another way, if you get here the SP is certainly screwed up
so getting the wrong (virtual) frame pointer is the least of your worries.
LGTM=iant
R=rsc, iant, lvd
CC=golang-codereviews
https://golang.org/cl/112750043
Both stdout and stderr are sent to /dev/null in android
apps. Introducing fatalf allows android to implement its
own copy that sends fatal errors to __android_log_print.
LGTM=minux, dave
R=minux, dave
CC=golang-codereviews
https://golang.org/cl/108400045
Based on cl/69170045 by Elias Naur.
There are currently several schemes for acquiring a TLS
slot to save the g register. None of them appear to work
for android. The closest are linux and darwin.
Linux uses a linker TLS relocation. This is not supported
by the android linker.
Darwin uses a fixed offset, and calls pthread_key_create
until it gets the slot it wants. As the runtime loads
late in the android process lifecycle, after an
arbitrary number of other libraries, we cannot rely on
any particular slot being available.
So we call pthread_key_create, take the first slot we are
given, and put it in runtime.tlsg, which we turn into a
regular variable in cmd/ld.
Makes android/arm cgo binaries work.
LGTM=minux
R=elias.naur, minux, dave, josharian
CC=golang-codereviews
https://golang.org/cl/106380043
The code in GC that handles gp->gobuf.ctxt is wrong,
because it does not mark the ctxt object itself,
if just queues the ctxt object for scanning.
So the ctxt object can be collected as garbage.
However, Gobuf.ctxt is void*, so it's always marked and
scanned through G.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, khr, rsc
https://golang.org/cl/105490044
runtime·usleep and runtime·osyield fall back to calling an
assembly wrapper for the libc functions in the absence of a m,
so they can be called in cgo callback context.
LGTM=rsc
R=minux.ma, rsc
CC=dave, golang-codereviews
https://golang.org/cl/102620044
A temporary 512 bytes buffer is allocated for every call to
readHeader. This buffer isn't returned to the caller and it could
be reused to lower the number of memory allocations.
This CL improves it by using a pool and zeroing out the buffer before
putting it back into the pool.
benchmark old ns/op new ns/op delta
BenchmarkListFiles100k 545249903 538832687 -1.18%
benchmark old allocs new allocs delta
BenchmarkListFiles100k 2105167 2005692 -4.73%
benchmark old bytes new bytes delta
BenchmarkListFiles100k 105903472 54831527 -48.22%
This improvement is very important if your code has to deal with a lot
of tarballs which contain a lot of files.
LGTM=dsymonds
R=golang-codereviews, dave, dsymonds, bradfitz
CC=golang-codereviews
https://golang.org/cl/108240044
A temporary 512 bytes buffer is allocated for every call to
writeHeader. This buffer could be reused the lower the number
of memory allocations.
benchmark old ns/op new ns/op delta
BenchmarkWriteFiles100k 634622051 583810847 -8.01%
benchmark old allocs new allocs delta
BenchmarkWriteFiles100k 2701920 2602621 -3.68%
benchmark old bytes new bytes delta
BenchmarkWriteFiles100k 115383884 64349922 -44.23%
This change is very important if your code has to write a lot of
tarballs with a lot of files.
LGTM=dsymonds
R=golang-codereviews, dave, dsymonds
CC=golang-codereviews
https://golang.org/cl/107440043
Thanks to Cedric Staub for noting that a short session key would lead
to an out-of-bounds access when conditionally copying the too short
buffer over the random session key.
LGTM=davidben, bradfitz
R=davidben, bradfitz
CC=golang-codereviews
https://golang.org/cl/102670044
The main changes fall into a few patterns:
1. Replace #define with enum.
2. Add /*c2go */ comment giving effect of #define.
This is necessary for function-like #defines and
non-enum-able #defined constants.
(Not all compilers handle negative or large enums.)
3. Add extra braces in struct initializer.
(c2go does not implement the full rules.)
This is enough to let c2go typecheck the source tree.
There may be more changes once it is doing
other semantic analyses.
LGTM=minux, iant
R=minux, dave, iant
CC=golang-codereviews
https://golang.org/cl/106860045
A TLS slot is reserved by _rt0_.*_plan9 as an automatic and
its address (which is static on Plan 9) is saved in the
global _privates symbol. The startup linkage now is exactly
like that from Plan 9 libc, and the way we access g is
exactly as if we'd have used privalloc(2).
Aside from making the code more standard, this change
drastically simplifies it, both for 386 and for amd64, and
makes the Plan 9 code in liblink common for both 386 and
amd64.
The amd64 runtime code was cleared of nxm assumptions, and
now runs on the standard Plan 9 kernel.
Note handling fixes will follow in a separate CL.
LGTM=rsc
R=golang-codereviews, rsc, bradfitz, dave
CC=0intro, ality, golang-codereviews, jas, minux.ma, mischief
https://golang.org/cl/101510049
We restored registers correctly in the usual case where the thread
is a Go-managed thread and called runtime·sighandler, but we
failed to do so when runtime·sigtramp was called on a cgo-created
thread. In that case, runtime·sigtramp called runtime·badsignal,
a Go function, and did not restore registers after it returned
LGTM=rsc, dave
R=rsc, dave
CC=golang-codereviews, minux.ma
https://golang.org/cl/105280050
On amd64, the real time is reduced from 176.76s to 140.26s.
On ARM, the real time is reduced from 921.61s to 726.30s.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/101580043
Move decAlloc calls a bit higher in the call tree.
Cleans code marginally, improves speed marginally.
The benchmarks are noisy but the median time from
20 consective 1-second runs improves by about 2%.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/105530043
3-index slices of the form s[:len(s):len(s)]
cannot be simplified to s[::len(s)].
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/108330043
We are not the right people to support editor plugins, and the profusion
of editors in this CL demonstrates the unreality of pretending to do so.
People are free to create and advertise their own repos with support.
For discussion: https://groups.google.com/forum/#!topic/golang-dev/SA7fD470FxU
LGTM=rminnich, kamil.kisiel, gri, rsc, dave, josharian, ruiu
R=golang-codereviews, rminnich, kamil.kisiel, gri, rsc, dominik.honnef, dave, josharian, ruiu, ajstarks
CC=golang-codereviews
https://golang.org/cl/105470043
There is no reason to generate different code for cap and len.
Fixes#8025.
Fixes#8026.
LGTM=rsc
R=rsc, iant, khr
CC=golang-codereviews
https://golang.org/cl/93570044
Breaks windows and race detector.
TBR=rsc
««« original CL description
runtime: stack allocator, separate from mallocgc
In order to move malloc to Go, we need to have a
separate stack allocator. If we run out of stack
during malloc, malloc will not be available
to allocate a new stack.
Stacks are the last remaining FlagNoGC objects in the
GC heap. Once they are out, we can get rid of the
distinction between the allocated/blockboundary bits.
(This will be in a separate change.)
Fixes#7468Fixes#7424
LGTM=rsc, dvyukov
R=golang-codereviews, dvyukov, khr, dave, rsc
CC=golang-codereviews
https://golang.org/cl/104200047
»»»
TBR=rsc
CC=golang-codereviews
https://golang.org/cl/101570044
In order to move malloc to Go, we need to have a
separate stack allocator. If we run out of stack
during malloc, malloc will not be available
to allocate a new stack.
Stacks are the last remaining FlagNoGC objects in the
GC heap. Once they are out, we can get rid of the
distinction between the allocated/blockboundary bits.
(This will be in a separate change.)
Fixes#7468Fixes#7424
LGTM=rsc, dvyukov
R=golang-codereviews, dvyukov, khr, dave, rsc
CC=golang-codereviews
https://golang.org/cl/104200047
The old code's structure needed to track indirections because of the
use of unsafe. That is no longer necessary, so we can remove all
that tracking. The code cleans up considerably but is a little slower.
We may be able to recover that performance drop. I believe the
code quality improvement is worthwhile regardless.
BenchmarkEndToEndPipe 5610 5780 +3.03%
BenchmarkEndToEndByteBuffer 3156 3222 +2.09%
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/103700043
If the actual types of two reflect values are
the same and the values are structs, they must
have the same number of fields.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/108280043
This removes a major unsafe thorn in our side, a perennial obstacle
to clean garbage collection.
Not coincidentally: In cleaning this up, several bugs were found,
including code that reached inside by-value interfaces to create
pointers for pointer-receiver methods. Unsafe code is just as
advertised.
Performance of course suffers, but not too badly. The Pipe number
is more indicative, since it's doing I/O that simulates a network
connection. Plus these are end-to-end, so each end suffers
only half of this pain.
The edit is pretty much a line-by-line conversion, with a few
simplifications and a couple of new tests. There may be more
performance to gain.
BenchmarkEndToEndByteBuffer 2493 3033 +21.66%
BenchmarkEndToEndPipe 4953 5597 +13.00%
Fixes#5159.
LGTM=rsc
R=rsc
CC=golang-codereviews, khr
https://golang.org/cl/102680045
The only text that describes the accepted format is in the package doc,
which is far away from these functions. The other flag types don't need
this explicitness because they are more obvious.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/101550043
Remove GC bitmap backward scanning.
This was already done once in https://golang.org/cl/5530074/
Still makes GC a bit faster.
On the garbage benchmark, before:
gc-pause-one=237345195
gc-pause-total=4746903
cputime=32427775
time=32458208
after:
gc-pause-one=235484019
gc-pause-total=4709680
cputime=31861965
time=31877772
Also prepares mgc0.c for future changes.
R=golang-codereviews, khr, khr
CC=golang-codereviews, rsc
https://golang.org/cl/105380043
newproc takes two extra pointers, not two extra registers.
On amd64p32 (nacl) they are different.
We diagnosed this before the 1.3 cut but the tree was frozen.
I believe this is causing the random problems on the builder.
Fixes#8199.
TBR=r
CC=golang-codereviews
https://golang.org/cl/102710043
Include these files in the build,
even though they don't get executed.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/108180043
Output number of spinning threads,
this is useful to understanding whether the scheduler
is in a steady state or not.
R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/103540045
Say when a goroutine is locked to OS thread in crash reports
and goroutine profiles.
It can be useful to understand what goroutines consume OS threads
(syscall and locked), e.g. if you forget to call UnlockOSThread
or leak locked goroutines.
R=golang-codereviews
CC=golang-codereviews, rsc
https://golang.org/cl/94170043
Pending acceptance of CL 101500044
and adjustment of test/fixedbugs/bug299.go.
LGTM=adonovan
R=golang-codereviews, adonovan
CC=golang-codereviews
https://golang.org/cl/110160043
The runtime has historically held two dedicated values g (current goroutine)
and m (current thread) in 'extern register' slots (TLS on x86, real registers
backed by TLS on ARM).
This CL removes the extern register m; code now uses g->m.
On ARM, this frees up the register that formerly held m (R9).
This is important for NaCl, because NaCl ARM code cannot use R9 at all.
The Go 1 macrobenchmarks (those with per-op times >= 10 µs) are unaffected:
BenchmarkBinaryTree17 5491374955 5471024381 -0.37%
BenchmarkFannkuch11 4357101311 4275174828 -1.88%
BenchmarkGobDecode 11029957 11364184 +3.03%
BenchmarkGobEncode 6852205 6784822 -0.98%
BenchmarkGzip 650795967 650152275 -0.10%
BenchmarkGunzip 140962363 141041670 +0.06%
BenchmarkHTTPClientServer 71581 73081 +2.10%
BenchmarkJSONEncode 31928079 31913356 -0.05%
BenchmarkJSONDecode 117470065 113689916 -3.22%
BenchmarkMandelbrot200 6008923 5998712 -0.17%
BenchmarkGoParse 6310917 6327487 +0.26%
BenchmarkRegexpMatchMedium_1K 114568 114763 +0.17%
BenchmarkRegexpMatchHard_1K 168977 169244 +0.16%
BenchmarkRevcomp 935294971 914060918 -2.27%
BenchmarkTemplate 145917123 148186096 +1.55%
Minux previous reported larger variations, but these were caused by
run-to-run noise, not repeatable slowdowns.
Actual code changes by Minux.
I only did the docs and the benchmarking.
LGTM=dvyukov, iant, minux
R=minux, josharian, iant, dave, bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/109050043
A single iteration of BenchmarkSaveRestore runs for 5 seconds
on my freebsd machine. 5 seconds looks like too long for a single
iteration.
This is the only benchmark that times out on freebsd-amd64-race builder.
R=golang-codereviews, dave
CC=golang-codereviews
https://golang.org/cl/107340044
Breaks the build
««« original CL description
cmd/go: build test files containing non-runnable examples
Even if we can't run them, we should at least check that they compile.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/107320046
»»»
TBR=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/110140044
Runs for 4 seconds on my mac.
Also this is the only test that times out on freebsd in -race mode.
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/110150045
This CL removes the special syntax for method receivers and
makes it just like other parameters. Instead, the crucial
receiver-specific rules (exactly one receiver, receiver type
must be of the form T or *T) are specified verbally instead
of syntactically.
This is a fully backward-compatible (and minor) syntax
relaxation. As a result, the following syntactic restrictions
(which are completely irrelevant) and which were only in place
for receivers are removed:
a) receiver types cannot be parenthesized
b) receiver parameter lists cannot have a trailing comma
The result of this CL is a simplication of the spec and the
implementation, with no impact on existing (or future) code.
Noteworthy:
- gc already permits a trailing comma at the end of a receiver
declaration:
func (recv T,) m() {}
This is technically a bug with the current spec; this CL will
legalize this notation.
- gccgo produces a misleading error when a trailing comma is used:
error: method has multiple receivers
(even though there's only one receiver)
- Compilers and type-checkers won't need to report errors anymore
if receiver types are parenthesized.
Fixes#4496.
LGTM=iant, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/101500044
Even if we can't run them, we should at least check that they compile.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/107320046
This CL re-applies the tests added in CL 101330053 and subsequently rolled back in CL 102610043.
The original author of this change was Rui Ueyama <ruiu@google.com>
LGTM=r, ruiu
R=ruiu, r
CC=golang-codereviews
https://golang.org/cl/109170043
The number of estimated iterations required to reach the benchtime is multiplied by a safety margin (to avoid falling just short) and then rounded up to a readable number. With an accurate estimate, in the worse case, the resulting number of iterations could be 3.75x more than necessary: 1.5x for safety * 2.5x to round up (e.g. from 2eX+1 to 5eX).
This CL reduces the safety margin to 1.2x. Experimentation showed a diminishing margin of return past 1.2x, although the average case continued to show improvements down to 1.05x.
This CL also reduces the maximum round-up multiplier from 2.5x (from 2eX+1 to 5eX) to 2x, by allowing the number of iterations to be of the form 3eX.
Both changes improve benchmark wall clock times, and the effects are cumulative.
From 1.5x to 1.2x safety margin:
package old s new s delta
bytes 163 125 -23%
encoding/json 27 21 -22%
net/http 42 36 -14%
runtime 463 418 -10%
strings 82 65 -21%
Allowing 3eX iterations:
package old s new s delta
bytes 163 134 -18%
encoding/json 27 23 -15%
net/http 42 36 -14%
runtime 463 422 -9%
strings 82 72 -12%
Combined:
package old s new s delta
bytes 163 112 -31%
encoding/json 27 20 -26%
net/http 42 30 -29%
runtime 463 346 -25%
strings 82 60 -27%
LGTM=crawshaw, r, rsc
R=golang-codereviews, crawshaw, r, rsc
CC=golang-codereviews
https://golang.org/cl/105990045
The previous call to parseRange already checks whether
all the ranges start before the end of file.
LGTM=robert.hencke, bradfitz
R=golang-codereviews, robert.hencke, gobot, bradfitz
CC=golang-codereviews
https://golang.org/cl/91880044
Update #1435
This proposal disables Setuid and Setgid on all linux platforms.
Issue 1435 has been open for a long time, and it is unlikely to be addressed soon so an argument was made by a commenter
https://code.google.com/p/go/issues/detail?id=1435#c45
That these functions should made to fail rather than succeed in their broken state.
LGTM=ruiu, iant
R=iant, ruiu
CC=golang-codereviews
https://golang.org/cl/106170043
MOV with SSE registers seems faster than REP MOVSQ if the
size being copied is less than about 2K. Previously we
didn't use MOV if the memory region is larger than 256
byte. This patch improves the performance of 257 ~ 2048
byte non-overlapping copy by using MOV.
Here is the benchmark result on Intel Xeon 3.5GHz (Nehalem).
benchmark old ns/op new ns/op delta
BenchmarkMemmove16 4 4 +0.42%
BenchmarkMemmove32 5 5 -0.20%
BenchmarkMemmove64 6 6 -0.81%
BenchmarkMemmove128 7 7 -0.82%
BenchmarkMemmove256 10 10 +1.92%
BenchmarkMemmove512 29 16 -44.90%
BenchmarkMemmove1024 37 25 -31.55%
BenchmarkMemmove2048 55 44 -19.46%
BenchmarkMemmove4096 92 91 -0.76%
benchmark old MB/s new MB/s speedup
BenchmarkMemmove16 3370.61 3356.88 1.00x
BenchmarkMemmove32 6368.68 6386.99 1.00x
BenchmarkMemmove64 10367.37 10462.62 1.01x
BenchmarkMemmove128 17551.16 17713.48 1.01x
BenchmarkMemmove256 24692.81 24142.99 0.98x
BenchmarkMemmove512 17428.70 31687.72 1.82x
BenchmarkMemmove1024 27401.82 40009.45 1.46x
BenchmarkMemmove2048 36884.86 45766.98 1.24x
BenchmarkMemmove4096 44295.91 44627.86 1.01x
LGTM=khr
R=golang-codereviews, gobot, khr
CC=golang-codereviews
https://golang.org/cl/90500043
sync.Pool is not supposed to be used everywhere, but is
a last resort.
««« original CL description
strings: use sync.Pool to cache buffer
benchmark old ns/op new ns/op delta
BenchmarkByteReplacerWriteString 3596 3094 -13.96%
benchmark old allocs new allocs delta
BenchmarkByteReplacerWriteString 1 0 -100.00%
LGTM=dvyukov
R=bradfitz, dave, dvyukov
CC=golang-codereviews
https://golang.org/cl/101330053
»»»
LGTM=dave
R=r, dave
CC=golang-codereviews
https://golang.org/cl/102610043
Fixes#8074.
The issue was not reproduceable by revision
go version devel +e0ad7e329637 Thu Jun 19 22:19:56 2014 -0700 linux/arm
But include the original test case in case the issue reopens itself.
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews
https://golang.org/cl/107290043
This requires minimal changes to the runtime hooks. In particular,
synchronization events must be done only on valid addresses now,
so I've added the additional checks to race.c.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/101000046
benchmark old ns/op new ns/op delta
BenchmarkByteReplacerWriteString 7359 3661 -50.25%
LGTM=dave
R=golang-codereviews, dave
CC=golang-codereviews
https://golang.org/cl/102550043
Afterprologue check was required when did not know
about return arguments of functions and/or they were not zeroed.
Now 100% precision is required for stacks due to stack copying,
so it must work w/o afterprologue one way or another.
I can limit this change for 1.3 to merely adding a TODO,
but this check is super confusing so I don't want this knowledge to get lost.
LGTM=rsc
R=golang-codereviews, gobot, rsc, khr
CC=golang-codereviews, khr, rsc
https://golang.org/cl/96580045
Use WriteString instead of allocating a byte slice as a
buffer. This was a TODO.
benchmark old ns/op new ns/op delta
BenchmarkWriteString 40139 19991 -50.20%
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/107190044
requires a decoder to do its own byte buffering instead of using
bufio.Reader, due to byte stuffing.
benchmark old MB/s new MB/s speedup
BenchmarkDecodeBaseline 33.40 50.65 1.52x
BenchmarkDecodeProgressive 24.34 31.92 1.31x
On 6g, unsafe.Sizeof(huffman{}) falls from 4872 to 964 bytes, and
the decoder struct contains 8 of those.
LGTM=r
R=r, nightlyone
CC=bradfitz, couchmoney, golang-codereviews, raph
https://golang.org/cl/109050045
This is a clone of 101370043, which I accidentally applied to the
release branch first.
No big deal, it needed to be applied there anyway.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/108090043
Storing temporary values to a slice is slower than storing
them to local variables of type byte.
benchmark old MB/s new MB/s speedup
BenchmarkEncodeToStringBase32 102.21 156.66 1.53x
BenchmarkEncodeToStringBase64 124.25 177.91 1.43x
LGTM=crawshaw
R=golang-codereviews, crawshaw, bradfitz, dave
CC=golang-codereviews
https://golang.org/cl/109820045
Just to be more thorough.
No need to push this to 1.3; it's just a test change that
worked without any changes to the code being tested.
LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews
https://golang.org/cl/109080045
genericReplacer.lookup is called for each byte of an input
string. In many (most?) cases, lookup will fail for the first
byte, and it will return immediately. Adding a fast path for
that case seems worth it.
Benchmark on my Xeon 3.5GHz Linux box:
benchmark old ns/op new ns/op delta
BenchmarkGenericNoMatch 2691 774 -71.24%
BenchmarkGenericMatch1 7920 8151 +2.92%
BenchmarkGenericMatch2 52336 39927 -23.71%
BenchmarkSingleMaxSkipping 1575 1575 +0.00%
BenchmarkSingleLongSuffixFail 1429 1429 +0.00%
BenchmarkSingleMatch 56228 55444 -1.39%
BenchmarkByteByteNoMatch 568 568 +0.00%
BenchmarkByteByteMatch 977 972 -0.51%
BenchmarkByteStringMatch 1669 1687 +1.08%
BenchmarkHTMLEscapeNew 422 422 +0.00%
BenchmarkHTMLEscapeOld 692 670 -3.18%
BenchmarkByteByteReplaces 8492 8474 -0.21%
BenchmarkByteByteMap 2817 2808 -0.32%
LGTM=rsc
R=golang-codereviews, bradfitz, dave, rsc
CC=golang-codereviews
https://golang.org/cl/79200044
Bug was introduced recently. Add more tests, fix the bugs.
Suppress + sign when not required in zero padding.
Do not zero pad infinities.
All old tests still pass.
This time for sure!
Fixes#8217.
LGTM=rsc
R=golang-codereviews, dan.kortschak, rsc
CC=golang-codereviews
https://golang.org/cl/103480043
Using flet to replace kill-region with delete-region was a hack,
flet is now (GNU Emacs 24.3) deprecated and at least two people
have reported an issue where using go--delete-whole-line would
permanently break their kill ring. While that issue is probably
caused by faulty third party code (possibly prelude), it's easier
to write a clean implementation than to tweak the hack.
LGTM=ruiu, adonovan
R=adonovan, ruiu
CC=adg, golang-codereviews
https://golang.org/cl/106010043
No functional changes.
Generating shorter functions improves compilation time. On my laptop, this test's running time goes from 5.5s to 1.5s; the wall clock time to run all tests goes down 1s. On Raspberry Pi, this CL cuts 50s off the wall clock time to run all tests.
Fixes#7503.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/72590045
The go:nosplit change wasn't the problem, reinstating.
««« original CL description
undo CL 93380044 / 7f0999348917
Partial undo, just of go:nosplit annotation. Somehow it
is breaking the windows builders.
TBR=bradfitz
««« original CL description
runtime: implement string ops in Go
Also implement go:nosplit annotation. Not really needed
for now, but we'll definitely need it for other conversions.
benchmark old ns/op new ns/op delta
BenchmarkRuneIterate 534 474 -11.24%
BenchmarkRuneIterate2 535 470 -12.15%
LGTM=bradfitz
R=golang-codereviews, dave, bradfitz, minux
CC=golang-codereviews
https://golang.org/cl/93380044
»»»
TBR=bradfitz
CC=golang-codereviews
https://golang.org/cl/105260044
»»»
TBR=bradfitz
R=bradfitz, golang-codereviews
CC=golang-codereviews
https://golang.org/cl/103490043
Partial undo, just of go:nosplit annotation. Somehow it
is breaking the windows builders.
TBR=bradfitz
««« original CL description
runtime: implement string ops in Go
Also implement go:nosplit annotation. Not really needed
for now, but we'll definitely need it for other conversions.
benchmark old ns/op new ns/op delta
BenchmarkRuneIterate 534 474 -11.24%
BenchmarkRuneIterate2 535 470 -12.15%
LGTM=bradfitz
R=golang-codereviews, dave, bradfitz, minux
CC=golang-codereviews
https://golang.org/cl/93380044
»»»
TBR=bradfitz
CC=golang-codereviews
https://golang.org/cl/105260044
Also implement go:nosplit annotation. Not really needed
for now, but we'll definitely need it for other conversions.
benchmark old ns/op new ns/op delta
BenchmarkRuneIterate 534 474 -11.24%
BenchmarkRuneIterate2 535 470 -12.15%
LGTM=bradfitz
R=golang-codereviews, dave, bradfitz, minux
CC=golang-codereviews
https://golang.org/cl/93380044
We don't need to shift array elements to shuffle them.
We just have to swap a selected element with 0th element.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/91750044
Printf("%x", "abc") was "0x610x620x63"; is now "0x616263", which
is surely better.
Printf("% #x", "abc") is still "0x61 0x62 0x63".
Fixes#8080.
LGTM=bradfitz, gri
R=golang-codereviews, bradfitz, gri
CC=golang-codereviews
https://golang.org/cl/106990043
Also added a test to verify os.Getppid() works across all platforms
LGTM=alex.brainman
R=golang-codereviews, alex.brainman, shreveal, iant
CC=golang-codereviews
https://golang.org/cl/102320044
Reportedly in the Linux 3.16 kernel the VDSO will not have
section headers or a normal symbol table.
Too late for 1.3 but perhaps for 1.3.1, if there is one.
Fixes#8197.
LGTM=rsc
R=golang-codereviews, mattn.jp, rsc
CC=golang-codereviews
https://golang.org/cl/101260044
bufio.Scanner.Scan returns whether the scan succeeded, not whether it
is done, so the test was mistakenly breaking early.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/93670045
makes windows-amd64-race benchmarks slower
««« original CL description
testing: make benchmarking faster
Allow the number of benchmark iterations to grow faster for fast benchmarks, and don't round up twice.
Using the default benchtime, this CL reduces wall clock time to run benchmarks:
net/http 49s -> 37s (-24%)
runtime 8m31s -> 5m55s (-30%)
bytes 2m37s -> 1m29s (-43%)
encoding/json 29s -> 21s (-27%)
strings 1m16s -> 53s (-30%)
LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews
https://golang.org/cl/101970047
»»»
TBR=josharian
CC=golang-codereviews
https://golang.org/cl/105950044
It appears that something about Go on Windows
cannot handle the fault cause by a jump to address 0.
The way Go represents and calls functions, this
never happened at all, until CL 105140044.
This CL changes the code added in CL 105140044
to make jump to 0 impossible once again.
Fixes#8047. (again, on Windows)
TBR=bradfitz
R=golang-codereviews, dave
CC=adg, golang-codereviews, iant, r
https://golang.org/cl/105120044
Rob asked for this change to make maintaining go1.4.txt easier.
If you are not sure of a change, it is still okay to send for review.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/109880044
jmpdefer modifies PC, SP, and LR, and not atomically,
so walking past jmpdefer will often end up in a state
where the three are not a consistent execution snapshot.
This was causing warning messages a few frames later
when the traceback realized it was confused, but given
the right memory it could easily crash instead.
Update #8153
LGTM=minux, iant
R=golang-codereviews, minux, iant
CC=golang-codereviews, r
https://golang.org/cl/107970043
The test requires that timerproc runs, but busy loops and starves
the scheduler so that, with high probability, timerproc doesn't run.
Avoid the issue by expecting the test to succeed; if not, a major
outside timeout will kill it and let us know.
As you can see from the diffs, there have been several attempts to
fix this with chicanery, but none has worked. Don't bother trying
any more.
Fixes#8136.
LGTM=rsc
R=rsc, josharian
CC=golang-codereviews
https://golang.org/cl/105140043
Allow the number of benchmark iterations to grow faster for fast benchmarks, and don't round up twice.
Using the default benchtime, this CL reduces wall clock time to run benchmarks:
net/http 49s -> 37s (-24%)
runtime 8m31s -> 5m55s (-30%)
bytes 2m37s -> 1m29s (-43%)
encoding/json 29s -> 21s (-27%)
strings 1m16s -> 53s (-30%)
LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews
https://golang.org/cl/101970047
Call copy with as large buffer as possible to reduce the
number of function calls.
benchmark old ns/op new ns/op delta
BenchmarkBytesRepeat 540 162 -70.00%
BenchmarkStringsRepeat 563 177 -68.56%
LGTM=josharian
R=golang-codereviews, josharian, dave, dvyukov
CC=golang-codereviews
https://golang.org/cl/90550043
Previously, an input string was stripped of newline
characters at the beginning of DecodeString and then passed
to Decode. Decode again tried to strip newline characters.
That's waste of time.
benchmark old MB/s new MB/s speedup
BenchmarkDecodeString 38.37 65.20 1.70x
LGTM=dave, bradfitz
R=golang-codereviews, dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/91770051
There is a hierarchy of location defined by loop depth:
-1 = the heap
0 = function results
1 = local variables (and parameters)
2 = local variable declared inside a loop
3 = local variable declared inside a loop inside a loop
etc
In general if an address from loopdepth n is assigned to
something in loop depth m < n, that indicates an extended
lifetime of some form that requires a heap allocation.
Function results can be local variables too, though, and so
they don't actually fit into the hierarchy very well.
Treat the address of a function result as level 1 so that
if it is written back into a result, the address is treated
as escaping.
Fixes#8185.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/108870044
Provide Nextafter64 as alias to Nextafter.
For submission after the 1.3 release.
Fixes#8117.
LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/101750048
The analysis for &x was using the loop depth on x set
during x's declaration. A type switch creates a list of
implicit declarations that were not getting initialized
with loop depths.
Fixes#8176.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/108860043
The putpclcdelta function set the DWARF line number PC to
s->value + pcline->pc, which is correct, but the code then set
the local variable pc to epc, which can be a different value.
This caused the next delta in the DWARF table to be wrong.
Fixes#8098.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/104950045
A runtime.Goexit during a panic-invoked deferred call
left the panic stack intact even though all the stack frames
are gone when the goroutine is torn down.
The next goroutine to reuse that struct will have a
bogus panic stack and can cause the traceback routines
to walk into garbage.
Most likely to happen during tests, because t.Fatal might
be called during a deferred func and uses runtime.Goexit.
This "not enough cleared in Goexit" failure mode has
happened to us multiple times now. Clear all the pointers
that don't make sense to keep, not just gp->panic.
Fixes#8158.
LGTM=iant, dvyukov
R=iant, dvyukov
CC=golang-codereviews
https://golang.org/cl/102220043
I am not sure what the rounding here was
trying to do, but it was skipping the first
pointer on native client.
The code above the rounding already checks
that xoffset is widthptr-aligned, so the rnd
was a no-op everywhere but on Native Client.
And on Native Client it was wrong.
Perhaps it was supposed to be rounding down,
not up, but zerorange handles the extra 32 bits
correctly, so the rnd does not seem to be necessary
at all.
This wouldn't be worth doing for Go 1.3 except
that it can affect code on the playground.
Fixes#8155.
LGTM=r, iant
R=golang-codereviews, r, iant
CC=dvyukov, golang-codereviews, khr
https://golang.org/cl/108740047
The current wording is reversed in 2 places.
Not sure how it got 4 LGTMs (mine was there as well).
Update #6242.
LGTM=dan.kortschak, r, rsc
R=golang-codereviews, 0xjnml, dan.kortschak, r, rsc
CC=golang-codereviews
https://golang.org/cl/101980047
It's not clear how widespread this issue is, but we do have a
test case generated by a development version of clang.
I don't know whether this should go into 1.3 or not; happy to
hear arguments either way.
LGTM=rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/96680045
I introduced this bug when I changed the escape
analysis to run in phases based on call graph
dependency order, in order to be more precise about
inputs escaping back to outputs (functions returning
their arguments).
Given
func f(z **int) *int { return *z }
we were tagging the function as 'z does not escape
and is not returned', which is all true, but not
enough information.
If used as:
var x int
p := &x
q := &p
leak(f(q))
then the compiler might try to keep x, p, and q all
on the stack, since (according to the recorded
information) nothing interesting ends up being
passed to leak.
In fact since f returns *q = p, &x is passed to leak
and x needs to be heap allocated.
To trigger the bug, you need a chain that the
compiler wants to keep on the stack (like x, p, q
above), and you need a function that returns an
indirect of its argument, and you need to pass the
head of the chain to that function. This doesn't
come up very often: this bug has been present since
June 2012 (between Go 1 and Go 1.1) and we haven't
seen it until now. It helps that most functions that
return indirects are getters that are simple enough
to be inlined, avoiding the bug.
Earlier versions of Go also had the benefit that if
&x really wasn't used beyond x's lifetime, nothing
broke if you put &x in a heap-allocated structure
accidentally. With the new stack copying, though,
heap-allocated structures containing &x are not
updated when the stack is copied and x moves,
leading to crashes in Go 1.3 that were not crashes
in Go 1.2 or Go 1.1.
The fix is in two parts.
First, in the analysis of a function, recognize when
a value obtained via indirect of a parameter ends up
being returned. Mark those parameters as having
content escape back to the return results (but we
don't bother to write down which result).
Second, when using the analysis to analyze, say,
f(q), mark parameters with content escaping as
having any indirections escape to the heap. (We
don't bother trying to match the content to the
return value.)
The fix could be less precise (simpler).
In the first part we might mark all content-escaping
parameters as plain escaping, and then the second
part could be dropped. Or we might assume that when
calling f(q) all the things pointed at by q escape
always (for any f and q).
The fix could also be more precise (more complex).
We might record the specific mapping from parameter
to result along with the number of indirects from the
parameter to the thing being returned as the result,
and then at the call sites we could set up exactly the
right graph for the called function. That would make
notleaks(f(q)) be able to keep x on the stack, because
the reuslt of f(q) isn't passed to anything that leaks it.
The less precise the fix, the more stack allocations
become heap allocations.
This fix is exactly as precise as it needs to be so that
none of the current stack allocations in the standard
library turn into heap allocations.
Fixes#8120.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, khr, r
https://golang.org/cl/102040046
The 'address taken' bit in a function variable was not
propagating into the inlined copies, causing incorrect
liveness information.
LGTM=dsymonds, bradfitz
R=golang-codereviews, bradfitz
CC=dsymonds, golang-codereviews, iant, khr, r
https://golang.org/cl/96670046
The 1-byte write was silently clearing a byte on the stack.
If there was another function call with more arguments
in the same stack frame, no harm done.
Otherwise, if the variable at that location was already zero,
no harm done.
Otherwise, problems.
Fixes#8139.
LGTM=dsymonds
R=golang-codereviews, dsymonds
CC=golang-codereviews, iant, r
https://golang.org/cl/100940043
This is a workaround - the code should be better than this - but the
fix avoids generating large numbers of linehist entries for the wrapper
functions that enable interface conversions. There can be many of
them, they all happen at the end of compilation, and they can all
share a linehist entry.
Avoids bad n^2 behavior in liblink.
Test case in issue 8135 goes from 64 seconds to 2.5 seconds (still bad
but not intolerable).
Fixes#8135.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/104840043
If we see a typedef to an anonymous struct more than once,
presumably in two different Go files that import "C", use the
same Go type name.
Fixes#8133.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/102080043
# CL 107530043 debug/elf: add (*File).DynamicSymbols, ErrNoSymbols, and tests for (*File).Symbols and (*File).DynamicSymbols, and formalize symbol order., Pietro Gagliardi <pietro10@mac.com>
<p>This page summarizes the changes between official stable releases of Go.
The <ahref="http://code.google.com/p/go/source/list">Mercurial change log</a>
has the full details.</p>
The <ahref="//golang.org/change">change log</a> has the full details.</p>
<p>To update to a specific release, use:</p>
<pre>
hg pull
hg update <i>tag</i>
git pull
git checkout <i>release-branch</i>
</pre>
<h2id="go1.4">go1.4 (released 2014/12/10)</h2>
<p>
Go 1.4 is a major release of Go.
Read the <ahref="/doc/go1.4">Go 1.4 Release Notes</a> for more information.
</p>
<h3id="go1.4.minor">Minor revisions</h3>
<p>
go1.4.1 (released 2015/01/15) includes bug fixes to the linker and the <code>log</code>, <code>syscall</code>, and <code>runtime</code> packages.
See the <ahref="https://github.com/golang/go/issues?q=milestone%3AGo1.4.1">Go 1.4.1 milestone on our issue tracker</a> for details.
</p>
<p>
go1.4.2 (released 2015/02/17) includes bug fixes to the <code>go</code> command, the compiler and linker, and the <code>runtime</code>, <code>syscall</code>, <code>reflect</code>, and <code>math/big</code> packages.
See the <ahref="https://github.com/golang/go/issues?q=milestone%3AGo1.4.2">Go 1.4.2 milestone on our issue tracker</a> for details.
</p>
<h2id="go1.3">go1.3 (released 2014/06/18)</h2>
<p>
Go 1.3 is a major release of Go.
Read the <ahref="/doc/go1.3">Go 1.3 Release Notes</a> for more information.
</p>
<h3id="go1.3.minor">Minor revisions</h3>
<p>
go1.3.1 (released 2014/08/13) includes bug fixes to the compiler and the <code>runtime</code>, <code>net</code>, and <code>crypto/rsa</code> packages.
See the <ahref="//code.google.com/p/go/source/list?name=release-branch.go1.3&r=073fc578434bf3e1e22749b559d273c8da728ebb">change history</a> for details.
</p>
<p>
go1.3.2 (released 2014/09/25) includes bug fixes to cgo and the crypto/tls packages.
See the <ahref="//code.google.com/p/go/source/list?name=release-branch.go1.3&r=go1.3.2">change history</a> for details.
</p>
<p>
go1.3.3 (released 2014/09/30) includes further bug fixes to cgo, the runtime package, and the nacl port.
See the <ahref="//code.google.com/p/go/source/list?name=release-branch.go1.3&r=go1.3.3">change history</a> for details.
</p>
<h2id="go1.2">go1.2 (released 2013/12/01)</h2>
<p>
@@ -24,12 +66,12 @@ Read the <a href="/doc/go1.2">Go 1.2 Release Notes</a> for more information.
<p>
go1.2.1 (released 2014/03/02) includes bug fixes to the <code>runtime</code>, <code>net</code>, and <code>database/sql</code> packages.
See the <ahref="https://code.google.com/p/go/source/list?name=release-branch.go1.2&r=7ada9e760ce34e78aee5b476c9621556d0fa5d31">change history</a> for details.
See the <ahref="//code.google.com/p/go/source/list?name=release-branch.go1.2&r=7ada9e760ce34e78aee5b476c9621556d0fa5d31">change history</a> for details.
that affects the tour binary included in the binary distributions (thanks to Guillaume T).
</p>
@@ -44,18 +86,18 @@ Read the <a href="/doc/go1.1">Go 1.1 Release Notes</a> for more information.
<p>
go1.1.1 (released 2013/06/13) includes several compiler and runtime bug fixes.
See the <ahref="https://code.google.com/p/go/source/list?name=release-branch.go1.1&r=43c4a41d24382a56a90e924800c681e435d9e399">change history</a> for details.
See the <ahref="//code.google.com/p/go/source/list?name=release-branch.go1.1&r=43c4a41d24382a56a90e924800c681e435d9e399">change history</a> for details.
</p>
<p>
go1.1.2 (released 2013/08/13) includes fixes to the <code>gc</code> compiler
and <code>cgo</code>, and the <code>bufio</code>, <code>runtime</code>,
<code>syscall</code>, and <code>time</code> packages.
See the <ahref="https://code.google.com/p/go/source/list?name=release-branch.go1.1&r=a6a9792f94acd4ff686b2bc57383d163608b91cf">change history</a> for details.
See the <ahref="//code.google.com/p/go/source/list?name=release-branch.go1.1&r=a6a9792f94acd4ff686b2bc57383d163608b91cf">change history</a> for details.
If you use package syscall's <code>Getrlimit</code> and <code>Setrlimit</code>
functions under Linux on the ARM or 386 architectures, please note change
This release fixes a <ahref="http://code.google.com/p/go/source/detail?r=b720749486e1">use of uninitialized memory in programs that misuse <code>goto</code></a>.
This release fixes a <ahref="//golang.org/change/b720749486e1">use of uninitialized memory in programs that misuse <code>goto</code></a>.
</p>
<h3id="r58.pkg">Packages</h3>
@@ -386,8 +428,8 @@ the Go tree (and avoid writing Makefiles).
<h3id="r58.minor">Minor revisions</h3>
<p>r58.1 adds
<ahref="http://code.google.com/p/go/source/detail?r=293c25943586">build</a> and
<p>The new <ahref="/cmd/gofix">gofix</a> tool finds Go programs that use old APIs and rewrites them to use
@@ -412,7 +454,7 @@ future changes to the libraries.
Gofix can’t
handle all situations perfectly, so read and test the changes it makes before
committing them.
See <ahref="http://blog.golang.org/2011/04/introducing-gofix.html">the gofix blog post</a> for more
See <ahref="//blog.golang.org/2011/04/introducing-gofix.html">the gofix blog post</a> for more
information.</p>
<h3id="r57.lang">Language</h3>
@@ -458,7 +500,7 @@ For clients, there are new
<ahref="/pkg/http/#Client">Client</a> and <ahref="/pkg/http/#Transport">Transport</a>
abstractions that give more control over HTTP details such as headers sent
and redirections followed. These abstractions make it easy to implement
custom clients that add functionality such as <ahref="http://code.google.com/p/goauth2/source/browse/oauth/oauth.go">OAuth2</a>.
custom clients that add functionality such as <ahref="//code.google.com/p/goauth2/source/browse/oauth/oauth.go">OAuth2</a>.
For servers, <ahref="/pkg/http/#ResponseWriter">ResponseWriter</a>
has dropped its non-essential methods.
The Hijack and Flush methods are no longer required;
@@ -502,7 +544,7 @@ implements all the possible value methods.
Instead of a type switch on a Value <code>v</code>, switch on <code>v.Kind()</code>.
Typeof and NewValue are now called <ahref="/pkg/reflect/#Type.TypeOf">TypeOf</a> and <ahref="/pkg/reflect/#Value.ValueOf">ValueOf</a>
To create a writable Value, use <code>New(t).Elem()</code> instead of <code>Zero(t)</code>.
See <ahref="http://code.google.com/p/go/source/detail?r=843855f3c026">the change description</a>
See <ahref="//golang.org/change/843855f3c026">the change description</a>
for the full details.
The new API allows a more efficient implementation of Value
that avoids many of the allocations required by the previous API.
@@ -538,8 +580,8 @@ For other uses, see the <a href="/pkg/runtime/pprof/">runtime/pprof</a> document
<h3id="r57.minor">Minor revisions</h3>
<p>r57.1 fixes a <ahref="http://code.google.com/p/go/source/detail?r=ff2bc62726e7145eb2ecc1e0f076998e4a8f86f0">nil pointer dereference in http.FormFile</a>.</p>
<p>r57.2 fixes a <ahref="http://code.google.com/p/go/source/detail?r=063b0ff67d8277df03c956208abc068076818dae">use of uninitialized memory in programs that misuse <code>goto</code></a>.</p>
<p>r57.1 fixes a <ahref="//golang.org/change/ff2bc62726e7145eb2ecc1e0f076998e4a8f86f0">nil pointer dereference in http.FormFile</a>.</p>
<p>r57.2 fixes a <ahref="//golang.org/change/063b0ff67d8277df03c956208abc068076818dae">use of uninitialized memory in programs that misuse <code>goto</code></a>.</p>
<p>This page summarizes the changes between tagged weekly snapshots of Go.
Such snapshots are no longer created. This page remains as a historical reference only.</p>
<p>For recent information, see the <ahref="http://code.google.com/p/go/source/list">Mercurial change log</a> and <ahref="http://groups.google.com/group/golang-dev/">development mailing list</a>.</p>
<p>For recent information, see the <ahref="//golang.org/change">change log</a> and <ahref="//groups.google.com/group/golang-dev/">development mailing list</a>.</p>
<h3id="go_tour"><ahref="http://tour.golang.org/">A Tour of Go</a></h3>
<h3id="go_tour"><ahref="//tour.golang.org/">A Tour of Go</a></h3>
<p>
An interactive introduction to Go in three sections.
The first section covers basic syntax and data structures; the second discusses
methods and interfaces; and the third introduces Go's concurrency primitives.
Each section concludes with a few exercises so you can practice what you've
learned. You can <ahref="http://tour.golang.org/">take the tour online</a> or
<ahref="http://code.google.com/p/go-tour/">install it locally</a>.
learned. You can <ahref="//tour.golang.org/">take the tour online</a> or
<ahref="//code.google.com/p/go-tour/">install it locally</a>.
</p>
<h3id="code"><ahref="code.html">How to write Go code</a></h3>
<p>
Also available as a
<ahref="http://www.youtube.com/watch?v=XCsL89YtqCs">screencast</a>, this doc
<ahref="//www.youtube.com/watch?v=XCsL89YtqCs">screencast</a>, this doc
explains how to use the <ahref="/cmd/go/">go command</a> to fetch, build, and
install packages, commands, and run tests.
</p>
@@ -103,7 +103,7 @@ same variable in a different goroutine.
<h2id="articles">Articles</h2>
<h3id="blog"><ahref="http://blog.golang.org/">The Go Blog</a></h3>
<h3id="blog"><ahref="//blog.golang.org/">The Go Blog</a></h3>
<p>The official blog of the Go project, featuring news and in-depth articles by
the Go team and guests.</p>
@@ -147,8 +147,8 @@ Guided tours of Go programs.
<li><ahref="/blog/godoc-documenting-go-code">Godoc: documenting Go code</a> - writing good documentation for <ahref="/cmd/godoc/">godoc</a>.</li>
<li><ahref="/blog/profiling-go-programs">Profiling Go Programs</a></li>
<li><ahref="/doc/articles/race_detector.html">Data Race Detector</a> - a manual for the data race detector.</li>
<li><ahref="/blog/race-detector">Introducing the Go Race Detector</a> - an introduction to the race detector.
<li><ahref="/doc/asm">A Quick Guide to Go's Assembler</a> - an introduction to the assembler used by Go.
<li><ahref="/blog/race-detector">Introducing the Go Race Detector</a> - an introduction to the race detector.</li>
<li><ahref="/doc/asm">A Quick Guide to Go's Assembler</a> - an introduction to the assembler used by Go.</li>
</ul>
<h4id="articles_more">More</h4>
@@ -169,17 +169,17 @@ interfaces, reflection, and concurrency. Builds a toy web crawler to
demonstrate these.
</p>
<h3id="go_code_that_grows"><ahref="http://vimeo.com/53221560">Code that grows with grace</a></h3>
<h3id="go_code_that_grows"><ahref="//vimeo.com/53221560">Code that grows with grace</a></h3>
<p>
One of Go's key design goals is code adaptability; that it should be easy to take a simple design and build upon it in a clean and natural way. In this talk Andrew Gerrand describes a simple "chat roulette" server that matches pairs of incoming TCP connections, and then use Go's concurrency mechanisms, interfaces, and standard library to extend it with a web interface and other features. While the function of the program changes dramatically, Go's flexibility preserves the original design as it grows.
Concurrency is the key to designing high performance network services. Go's concurrency primitives (goroutines and channels) provide a simple and efficient means of expressing concurrent execution. In this talk we see how tricky concurrency problems can be solved gracefully with simple Go code.
</p>
<h3id="advanced_go_concurrency_patterns"><ahref="http://www.youtube.com/watch?v=QDDwwePbDtw">Advanced Go Concurrency Patterns</a></h3>
<h3id="advanced_go_concurrency_patterns"><ahref="//www.youtube.com/watch?v=QDDwwePbDtw">Advanced Go Concurrency Patterns</a></h3>
<p>
This talk expands on the <i>Go Concurrency Patterns</i> talk to dive deeper into Go's concurrency primitives.
The changes to <ahref="http://code.google.com/p/go/source/detail?r=2646dc956207">encoding/gob</a> and the <ahref="http://code.google.com/p/goprotobuf/source/detail?r=5340ad310031">protocol buffer library</a>
The changes to <ahref="//golang.org/change/2646dc956207">encoding/gob</a> and the <ahref="//code.google.com/p/goprotobuf/source/detail?r=5340ad310031">protocol buffer library</a>
may be helpful as examples.
</p>
@@ -2035,4 +2035,4 @@ They are available for many combinations of architecture and operating system
Installation details are described on the
<ahref="/doc/install">Getting Started</a> page, while
with the Go project's source rather than release downloads sometimes
ask for the project to switch to git.
That would be possible, but it would be a lot of work and
would also require reimplementing the codereview plugin.
Given that Mercurial works today, with code review support,
combined with the Go project's mostly linear, non-branching use of
version control, a switch to git doesn't seem worthwhile.
</p>
<h3id="git_https">
Why does "go get" use HTTPS when cloning a repository?</h3>
@@ -1110,7 +1089,7 @@ error but the situation can still be confusing, because sometimes a
<ahref="#different_method_sets">pointer
is necessary to satisfy an interface</a>.
The insight is that although a pointer to a concrete type can satisfy
an interface, with one exception <em>a pointer to an interface can never satisfy a interface</em>.
an interface, with one exception <em>a pointer to an interface can never satisfy an interface</em>.
</p>
<p>
@@ -1304,7 +1283,7 @@ Do not communicate by sharing memory. Instead, share memory by communicating.
</p>
<p>
See the <ahref="/doc/codewalk/sharemem/">Share Memory By Communicating</a> code walk and its <ahref="http://blog.golang.org/2010/07/share-memory-by-communicating.html">associated article</a> for a detailed discussion of this concept.
See the <ahref="/doc/codewalk/sharemem/">Share Memory By Communicating</a> code walk and its <ahref="//blog.golang.org/2010/07/share-memory-by-communicating.html">associated article</a> for a detailed discussion of this concept.
</p>
<h3id="Why_no_multi_CPU">
@@ -1321,7 +1300,7 @@ run-time support to utilize more than one OS thread.
Programs that perform parallel computation should benefit from an increase in
distributions</a> are available for the FreeBSD (release 8-STABLE and above),
Linux, Mac OS X (Snow Leopard and above), and Windows operating systems and
the 32-bit (<code>386</code>) and 64-bit (<code>amd64</code>) x86 processor
architectures.
</p>
<p>
@@ -44,10 +45,10 @@ proceeding. If your OS or architecture is not on the list, it's possible that
<thalign="center">Notes</th>
</tr>
<tr><tdcolspan="3"><hr></td></tr>
<tr><td>FreeBSD 8 or later</td><td>amd64, 386, arm</td><td>Debian GNU/kFreeBSD not supported; FreeBSD/ARM needs FreeBSD 10 or later</td></tr>
<tr><td>FreeBSD 8-STABLE or later</td><td>amd64, 386, arm</td><td>Debian GNU/kFreeBSD not supported; FreeBSD/ARM needs FreeBSD 10 or later</td></tr>
<tr><td>Linux 2.6.23 or later with glibc</td><td>amd64, 386, arm</td><td>CentOS/RHEL 5.x not supported; no binary distribution for ARM yet</td></tr>
<tr><td>Mac OS X 10.6 or later</td><td>amd64, 386</td><td>use the gcc<sup>†</sup> that comes with Xcode<sup>‡</sup></td></tr>
<tr><td>Windows XP or later</td><td>amd64, 386</td><td>use MinGW gcc<sup>†</sup>. No need for cgywin or msys.</td></tr>
<tr><td>Windows XP or later</td><td>amd64, 386</td><td>use MinGW gcc<sup>†</sup>. No need for cygwin or msys.</td></tr>
</table>
<p>
@@ -70,7 +71,7 @@ first <a href="#uninstall">remove the existing version</a>.
<h3id="tarball">Linux, Mac OS X, and FreeBSD tarballs</h3>
<p>
<ahref="https://code.google.com/p/go/wiki/Downloads?tm=2">Download the archive</a>
<ahref="https://golang.org/dl/">Download the archive</a>
and extract it into <code>/usr/local</code>, creating a Go tree in
<code>/usr/local/go</code>. For example:
</p>
@@ -127,7 +128,7 @@ location.
<h3id="osx">Mac OS X package installer</h3>
<p>
<ahref="https://code.google.com/p/go/wiki/Downloads?tm=2">Download the package file</a>,
<ahref="https://golang.org/dl/">Download the package file</a>,
open it, and follow the prompts to install the Go tools.
The package installs the Go distribution to <code>/usr/local/go</code>.
</p>
@@ -150,7 +151,7 @@ MSI installer that configures your installation automatically.
<h4id="windows_msi">MSI installer</h4>
<p>
Open the <ahref="https://code.google.com/p/go/wiki/Downloads?tm=2">MSI file</a>
Open the <ahref="https://golang.org/dl/">MSI file</a>
and follow the prompts to install the Go tools.
By default, the installer puts the Go distribution in <code>c:\Go</code>.
</p>
@@ -164,7 +165,7 @@ command prompts for the change to take effect.
<h4id="windows_zip">Zip archive</h4>
<p>
<ahref="https://code.google.com/p/go/wiki/Downloads?tm=2">Download the zip file</a> and extract it into the directory of your choice (we suggest <code>c:\Go</code>).
<ahref="https://golang.org/dl/">Download the zip file</a> and extract it into the directory of your choice (we suggest <code>c:\Go</code>).
</p>
<p>
@@ -224,19 +225,12 @@ If you see the "hello, world" message then your Go installation is working.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
