Recreation of CL 206139 in the new symbol hierarchy.
Change-Id: Ic20c5c1b5db8f7eadf4c6ee4638e3c1a4e10ef3a
Reviewed-on: https://go-review.googlesource.com/c/go/+/219317
Run-TryBot: Jeremy Faller <jeremy@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
With unique global indices, MakeSymbolUpdater will not change the
symbol's index. So no need to return a new index.
Change-Id: I5b4fd6a0167cc74476880bbf4382c524ecde7721
Reviewed-on: https://go-review.googlesource.com/c/go/+/219227
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, the loader adds defined package symbols and
non-package symbols to the global index space object by object.
This CL changes it to add all the defined package symbols first,
then all the non-package symbols. The advantage of doing this is
that when adding package symbols, by definition they cannot be
dup to each other, so we don't need to do a name lookup when
adding them.
We still add them to the lookup table (for now), since they may
still be referenced by name (e.g. through linkname). This CL is
also a prerequisite if we want to move to not adding package
symbols to the lookup table entirely (e.g. by using
pre-generated in-file lookup table).
Also update some comments to reflect the current state.
Change-Id: Ib757e070b48a9ef6215e47dc3421fc5c055b746c
Reviewed-on: https://go-review.googlesource.com/c/go/+/219078
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Most of the time of goobj2.Sym.Read is spent in reading the
symbol name. Sometimes the name is not needed, so don't read
it.
This brings the linking time pretty much back to the old linker.
On my Mac,
$ time go build cmd/compile # (new)
real 0m1.016s
user 0m1.164s
sys 0m0.297s
$ time go-tip build cmd/compile # (old)
real 0m0.980s
user 0m1.229s
sys 0m0.309s
Again, this is a bit ugly. Maybe we want to consider moving
symbol names out of Sym, to a separate section of the object
file?
Change-Id: Ia9085c15aa4d614b7eae126e71a79d6806c75055
Reviewed-on: https://go-review.googlesource.com/c/go/+/218480
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reading unnecessary fields from object file take time, even from
memory mapping. In deadcode, we do this a alot, so only read
necessary ones. In particular, for relocations, for non-type
symbols, we only need their target symbols and reloc types to
build the dependency graph, so don't read other fields. This
should speed up the deadcode pass.
Also cache an object's number of defined package symbols, as it
is accessed a lot in resolve.
This is a bit ugly from an API point of view. It would be nice if
the compiler could figure out some fields are not used so don't
fill them.
Change-Id: I5c4e9526b8a3b0aead9fa71901a51fb214f013a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/218479
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
With the new index mapping , we can clean up some fields.
Loader.max should always be equal to len(loader.objSyms) now. And
for external symbols we now give its "local index" as its index
in the payload array, so Relocs.extIdx is no longer useful.
Delete those fields.
Change-Id: If387ff9201ea0d347b954f651f5d4b4ae74937aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/218478
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
This reverts commit 494dd1dddc.
Reason for revert: Not suitable for Go 1.14, will send to Go 1.15 instead.
Change-Id: Iedc04fe6a9ace29a16498046eef9420afbaf4636
Reviewed-on: https://go-review.googlesource.com/c/go/+/218482
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
HTML pages served by the website have the option to opt-in to template
processing, by including "Template: true" in the page metadata.
This functionality is documented at
403f1254bd/godoc/template.go (L5-L30).
Historically, the Go 1 release notes have used template processing
to a great extent, but release notes for all subsequent major Go
releases have not.
Since this feature is generally not used and not very well known,
it tends to do more harm than good by making it possible for errors
in the template to prevent the release notes from showing up at all.
Disable this feature for Go 1.14 release notes and onwards.
We can consider enabling it when there's a stronger need for it.
Fixes#37072
Updates #37070
Change-Id: If93553d52df12544b46c4edcf3aa5eddc2a155ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/218058
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This caused 35 test failures in Google internal code,
so it's worth mentioning in the release notes.
Updates #31810
Updates #36878Fixes#37066
Change-Id: I2faa6bce4c7d735107eceaef7d95223844846454
Reviewed-on: https://go-review.googlesource.com/c/go/+/217978
Reviewed-by: Rob Pike <r@golang.org>
Documents io/ioutil.TempDir's new ability to create
predictable prefixes and suffixes, derived from the argument
'pattern', separated by the last '*' in it.
References: CL 198488
Updates #36878
Change-Id: I92c52fcc7d480ce74746e99e6e85a04efb87294f
Reviewed-on: https://go-review.googlesource.com/c/go/+/217780
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This commit changes the wording of a comment in malloc.go that describes
how span objects are zeroed to make it more clear.
Change-Id: I07722df1e101af3cbf8680ad07437d4a230b0168
GitHub-Last-Rev: 0e909898c7
GitHub-Pull-Request: golang/go#37008
Reviewed-on: https://go-review.googlesource.com/c/go/+/217618
Reviewed-by: Austin Clements <austin@google.com>
It was removed in CL 217302 but was intentionally added in CL 217104.
Change-Id: I1a478d80ad1ec4f0a0184bfebf8f1a5e352cfe8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/217941
Reviewed-by: Robert Griesemer <gri@golang.org>
In CL 217064, we made symbol's global index unique, but we still
reserve index space for each object file, which means we may
leave holes in the index space if the symbol is a dup or is
overwritten. In this CL, we stop reserving index spaces. Instead,
symbols are added one at a time, and only added if it does not
already exist. There is no more holes in the index space.
Change-Id: I3c4e67163c556ba1198e13065706510dac4692fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/217519
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
We have converted all the host object readers to the new loader
based mechanism, and no longer do sym.Symbol host object loading.
Remove that support. So we don't have to take care of that in
future changes to the loader.
TODO: there are still code outside the loader than can be
removed. This CL only focuses on the loader.
Change-Id: I67dd75f631964921a7c7a6576ed95b071241484a
Reviewed-on: https://go-review.googlesource.com/c/go/+/217518
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Now that we have local-global index mappings, just use that for
symbol reference resolution.
Change-Id: I6bc5405853fe040ff21b624ccd8da7965d66ec8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/217065
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Document that for Windows, net/http.ServeFile can now
correctly serve files >2GB after we fixed internal/poll.SendFile
to transmit files larger than the default Windows limit of 2GB.
References: CL 192518, CL 194218
Updates #36878
Change-Id: Ibefc8b2841bc0cee3a89884a680085f99d2b6928
Reviewed-on: https://go-review.googlesource.com/c/go/+/217779
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In CL 199417, we updated “How to Write Go Code” to give a basic
introduction to modules and to include module-mode commands.
However, most new users will end up reading “Getting Started”
(doc/install.html) before “How to Write Go Code”, and we forgot to
update the handful of commands there for module mode.
Before this change, the “Test your installation” section also covered
quite a few operations beoyond merely testing the installation: it
included setting up a GOPATH, building a binary, and installing and
cleaning binaries. Those are valuable operations to learn, but they
arguably belong in “How to Write Go Code”, not “Test your
installation” — and having all that extra detail in the install
instructions may well discourage folks from further essential reading.
Rather than updating all of those operations here, I've removed them.
A companion CL will update “How to Write Go Code” to ensure that it
mentions GOPATH (as the location of the module cache and the default
install location for binaries) and 'go clean -i'.
Updates #37042
Change-Id: I157f21ccbe3896575fa1115dc821abf6c71ed15e
Reviewed-on: https://go-review.googlesource.com/c/go/+/217840
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tyler Bui-Palsulich <tbp@google.com>
These 3 release notes have had an element ID collision because both
the runtime changes and changes to the package "runtime" used the
same ID. Fix it by using a "pkg-" prefix for the runtime package.
Move the "runtime-again" ID from CL 129635 to a nearby <dt> element
so that existing links to https://golang.org/doc/go1.11#runtime-again
don't break.
Fixes#37036
Updates #36878
Change-Id: Ib68d93acfac802fd84c0a57485937e45dea2064a
Reviewed-on: https://go-review.googlesource.com/c/go/+/217797
Reviewed-by: Toshihiro Shiino <shiino.toshihiro@gmail.com>
Reviewed-by: Agniva De Sarker <agniva.quicksilver@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
net.LookupHost("foo\x00bar") may resolve successfully on some networks.
Reduce the scope of the test to check only that the call doesn't panic.
Also update the test comment to reference the relevant issue.
Fixes#37031
Updates #31597
Change-Id: If175deed8121625ef507598c6145e937ccffd89e
Reviewed-on: https://go-review.googlesource.com/c/go/+/217729
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It's possible for the scheduler to try to preempt a goroutine running
on a thread created by C code just as the goroutine returns from Go code
to C code. If that happens, the goroutine will have a nil g,
which would normally cause us to enter the badsignal code.
The badsignal code will allocate an M, reset the signal handler,
and raise the signal. This is all wasted work for SIGURG,
as the default behavior is for the kernel to ignore the signal.
It also means that there is a period of time when preemption requests
are ignored, because the signal handler is reset to the default.
And, finally, it triggers a bug on 386 OpenBSD 6.2. So stop doing it.
No test because there is no real change in behavior (other than on OpenBSD),
the new code is just more efficient
Fixes#36996
Change-Id: I8c1cb9bc09f5ef890cab567924417e2423fc71f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/217617
Reviewed-by: Austin Clements <austin@google.com>
Previously, the release notes broke up the sentences that modules
is now ready for production use and where to file issues for
migration problems into separate paragraphs. This made it look like
the migration paragraph was about upgrading to 1.14, not to modules,
and made the reading a bit confusing. Now the entire idea is in one
paragraph.
Change-Id: I10bddfb8aba5f5909ac6842f25e3e97d505835e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/217720
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This reverts CL 217417 (commit 753d56d364).
This change was unintentionally submitted to master during the
Go 1.14 code freeze; it should be sent again for Go 1.15.
Change-Id: Ie790342f227ae3adfc5f9a90ce3abdc2c9be619b
Reviewed-on: https://go-review.googlesource.com/c/go/+/217721
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
The solaris-amd64-oraclerel builder is passing for the main Go repo
(on tip and release branches for 1.13 and 1.12), and golang.org/x repos
(also on tip and release branches for 1.13 and 1.12).
The builder is still maintained as described at
https://golang.org/issue/15581#issuecomment-550368581.
Updates #36878
Updates #15581
Change-Id: Icc6f7529ca2e05bb34f09ce4363d9582e80829c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/217738
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
There is an active builder that was added in CL 201597,
and it is passing on Go tip and release-branch.go1.13
(with one failure that appears to be flaky due to being
out of memory). It's also passing on all golang.org/x repos
on tip and release-branch.go1.13. It's not configured to
run on Go 1.12 release branches.
Updates #36878
Updates #15581
Change-Id: I4ed7fc62c11a09743832fca39bd61fa0cf6e7ded
Reviewed-on: https://go-review.googlesource.com/c/go/+/217737
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Both the Dragonfly release and tip builder have been passing for a
while. The net package's interface API is working on both builders since
CL 202317 which has been re-vendored in CL 202438.
Updates #34368
Updates #36878
Change-Id: I187178b3a59f2604187af453207fb4e24a56105c
Reviewed-on: https://go-review.googlesource.com/c/go/+/217358
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This saves a redirect and makes the document more consistent.
Change-Id: I67840f5dc05dffd8893a055618eb202b682a0ebc
Reviewed-on: https://go-review.googlesource.com/c/go/+/217698
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A js.Func object in fsCall was created for each call but never
released. This CL fixes this.
Change-Id: I2e2b504cbf4fb130b8cfe890a66d3a66aadf56a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/217417
Run-TryBot: Hajime Hoshi <hajimehoshi@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Agniva De Sarker <agniva.quicksilver@gmail.com>
Reviewed-by: Richard Musiol <neelance@gmail.com>
We don't usually document past behavior (like "As of Go 1.14 ...") and
in isolation the current docs made it sound like a and b could only be
negative or zero.
Change-Id: I0d3c2b8579a9c01159ce528a3128b1478e99042a
Reviewed-on: https://go-review.googlesource.com/c/go/+/217302
Reviewed-by: Ian Lance Taylor <iant@golang.org>
GCD is a method, not a function, so the link was broken.
Change-Id: Icbb09d39959e7c71a48987b15bb82febe12c3a19
Reviewed-on: https://go-review.googlesource.com/c/go/+/217303
Reviewed-by: Ian Lance Taylor <iant@golang.org>
