Currently, when mapping symbol's local index to global index, for
duplicated and overwriting/overwritten symbols, each appearance
of the symbol gets a global index, with one being the "primary",
and others "redirect" to it through the overwrite map. Basically,
the local-global index mapping is one to one, with overwrite/
dedup happening in global index level.
This has a few drawbacks:
- All symbol accesses effectively need to query the overwrite
map. This may hurt performance.
- For multi-level overwrites, (Y overwrites X, Z overwrites Y),
this can get quite complicated, and we have to follow the
redirection recursively.
- Failed to follow or to update the overwrite map leads to bugs.
In this CL, we change the index mapping mechanism so that each
symbol get a unique global index. Multiple appearances of the
same symbol get the same index. Now the local-global index
mapping is N to one. Overwrite/dedup happens directly in the
local-global mapping.
We keep both mapping directions in arrays. Each object carries
an array for its local-global mapping. The loader carries an
array mapping global index to the "primary" local index, which is
the one we should load from. This way, we can get rid of the
overwrite map, and index conversions are simply array accesses.
TODO: we still make reservation of the index space upfront, and
leave holes for dup symbols. Maybe get rid of the reservation and
holes.
Change-Id: Ia251489d5f2ff16a0b3156a71d141a70cdf03a4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/217064
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
It has been a while we have not done this.
Merge conflict resolution:
- deleted/rewritten code modified on master
- CL 214286, ported in CL 217317
(cmd/internal/obj/objfile.go)
- CL 210678, it already includes a fix to new code
(cmd/link/internal/ld/deadcode.go)
- CL 209317, applied in this CL
(cmd/link/internal/loadelf/ldelf.go)
Change-Id: Ie927ea6a1d69ce49e8d03e56148cb2725e377876
Port CL 214286 to new object files. This is in preparation of
merging master branch to dev.link.
Change-Id: I8cd93908a795c03b8c44df47f66728017c542f4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/217317
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Currently, the symbol updater uses a pointer pointing to the
loader's payloads array. If the payloads slice grows (and moves),
the pointer may become stale and no longer point to the symbol's
actual payload. Specifically, consider
sb, sym := l.MakeSymbolUpdater(...)
// add a bunch of external symbols, which grows payload slice
sb.SetType(t)
l.SymType(sym) // may not return t
sb.SetType on line 3 may not have the desired effect, as
sb.extSymPayload may no longer point to the right payload. As a
result, the type we get on line 4 may be not the one we set.
Fix this by making the payload's address permanent. Once it is
allocated it will never move.
Change-Id: Iab190ea5aceb5c37f91d09ad4ffd458e881b03f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/217063
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
This was mistakenly changed during the refactor in CL 201728.
Restore the old behavior.
Change-Id: I9991859e7587f5f567bbe86ae19dede904b3a399
Reviewed-on: https://go-review.googlesource.com/c/go/+/217062
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Some tweaks based on comments from CL 216917.
Change-Id: I538ea0dfa947b53d5c4a7135c1aec912b0357083
Reviewed-on: https://go-review.googlesource.com/c/go/+/217121
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Implementation changes in go/types for #6977 required that internal
LookupFieldOrMethod calls had access to the current *Checker. In
order to make quick progress, I added a *Checker receiver to the
function LookupFieldOrMethod (thus making it a method), and added
a new function LookupFieldOrMethod. The plan was always to rename
that function (Checker.LookupFieldOrMethod) such that it wouldn't
be exported; with the obvious name being Checker.lookupFieldOrMethod.
But that name was already in use which is why I postponed the rename.
Eventually I forgot to clean it up. This CL fixes that with the
following renames:
Checker.lookupFieldOrMethod => Checker.rawLookupFieldOrMethod
Checker.LookupFieldOrMethod => Checker.lookupFieldOrMethod
Updates #6977.
Fixes#36916.
Change-Id: Icfafd0de9a19841ba5bd87142730fe7323204491
Reviewed-on: https://go-review.googlesource.com/c/go/+/217134
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Minor edits to text on go command changes.
Also, moved a note about runtime respecting zone CPU caps from
Native Client section to Runtime section.
Change-Id: Ic21e59d7ffecb4b5676a841e7f3743203a82d266
Reviewed-on: https://go-review.googlesource.com/c/go/+/216878
Reviewed-by: Bryan C. Mills <bcmills@google.com>
In CL 203820, we switched go/build to use the caller's working
directory for the main module (rather than srcDir), so that go/build
resolution now respects the requirements and replacements of the main
module. When the passed-in srcDir is empty, as of that CL we use "go
list" instead of falling back to in-process (GOPATH-mode) path lookup.
Unfortunately, that broke go/build.TestImportDirNotExist when
GO111MODULE=on: the test was looking for the specific error message
produced by the in-process lookup.
This change relaxes the test to accept the error message produced by
"go list" when srcDir is empty.
Updates #34769
Updates #34860
Updates #35734Fixes#36867
Change-Id: Id0f7814a4b7dabe8917216eb013bb4eaee283648
Reviewed-on: https://go-review.googlesource.com/c/go/+/216817
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Now that the other dependent offset has been identified, we can remove the
unnecessary ADDI instruction from the riscv64 call sequence (reducing it
to AUIPC+JALR, rather than the previous AUIPC+ADDI+JALR).
Change-Id: I348c4efb686f9f71ed1dd1d25fb9142a41230b0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/216798
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The R_CALLRISCV relocation marker is on the JALR instruction, however the actual
relocation is currently two instructions previous for the AUIPC+ADDI sequence.
Adjust the platform dependent offset accordingly and re-enable open-coded defers.
Fixes#36786.
Change-Id: I71597c193c447930fbe94ce44b7355e89ae877bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/216797
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Fixes#36690.
Change-Id: Id4234ab9467270d51f0411375b71ece7f41269b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/215817
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
As of CL 175857, the client code checks for known round tripper
implementations, and uses simpler cancellation code when it finds one.
However, this code was not considering the case of a request that uses
a user-defined protocol, where the user-defined protocol was
registered with the transport to use a different round tripper.
The effect was that round trippers that worked with earlier
releases would not see the expected cancellation semantics with tip.
Fixes#36820
Change-Id: I60e75b5d0badcfb9fde9d73a966ba1d3f7aa42b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/216618
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This test expects that open-coded defers are enabled, which is not currently
the case on riscv64.
Updates issue #27532 and #36786.
Change-Id: I94bb558c5b0734b4cfe5ae12873be81026009bcf
Reviewed-on: https://go-review.googlesource.com/c/go/+/216777
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change formalizes an assumption made by the page allocator, which
is that (*pageAlloc).searchAddr should never refer to memory that is not
represented by (*pageAlloc).inUse. The portion of address space covered
by (*pageAlloc).inUse reflects the parts of the summary arrays which are
guaranteed to mapped, and so looking at any summary which is not
reflected there may cause a segfault.
In fact, this can happen today. This change thus also removes a
micro-optimization which is the only case which may cause
(*pageAlloc).searchAddr to point outside of any region covered by
(*pageAlloc).inUse, and adds a test verifying that the current segfault
can no longer occur.
Change-Id: I98b534f0ffba8656d3bd6d782f6fc22549ddf1c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/216697
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
cryptobyte: fix panic due to malformed ASN.1 inputs on 32-bit archs
When int is 32 bits wide (on 32-bit architectures like 386 and arm), an
overflow could occur, causing a panic, due to malformed ASN.1 being
passed to any of the ASN1 methods of String.
Tested on linux/386 and darwin/amd64.
This fixes CVE-2020-7919 and was found thanks to the Project Wycheproof
test vectors.
Change-Id: I8c9696a8bfad1b40ec877cd740dba3467d66ab54
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/645211
Reviewed-by: Katie Hockman <katiehockman@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/216677
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
x/crypto/cryptobyte is used in crypto/x509 for parsing certificates.
Malformed certificates might cause a panic during parsing on 32-bit
architectures (like arm and 386).
Change-Id: I840feb54eba880dbb96780ef7adcade073c4c4e3
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/647741
Reviewed-by: Katie Hockman <katiehockman@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/216680
Reviewed-by: Katie Hockman <katie@golang.org>
No real reason to keep the old code around as the new stuff is working
just fine.
Change-Id: I5e886f8274344738663a0ead181c5d58d9f5a45f
Reviewed-on: https://go-review.googlesource.com/c/go/+/215997
Run-TryBot: Jeremy Faller <jeremy@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Open-coded defers are currently broken on riscv64 - disable them for the
time being. All of the standard package tests now pass on linux/riscv64.
Updates issue #27532 and #36786
Change-Id: I20fc25ce91dfad48be32409ba5c64ca9a6acef1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/216517
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
On RISCV64, the U-instructions (AUIPC and LUI) take 20 bits, append 12 bits
of zeros and sign extend to 64-bits. As such, the 20 bit immediate value is
signed not unsigned.
Updates #27532
Change-Id: I725215a1dc500106dbfdc0a4425f3c0b2a6f411e
Reviewed-on: https://go-review.googlesource.com/c/go/+/216257
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Duplicate the register definitions and names to avoid importing the
cmd/internal/obj/riscv64 package. This makes it possible to build compiler rules
with a stable Go tool chain.
Fixes#36663
Change-Id: I09116a97bb037ca1bc00073306a82bb88862b1e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/216518
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Hopefully this won't affect many people, but it's a substantial change
in behavior for a specific case, so it's probably worth mentioning.
Updates #32027
Change-Id: I61cd50e93d0199e94b011cc90150e072b6bb10ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/216597
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
On PPC64, MOVWload, MOVDload, and MOVDstore are assembled to a
"DS from" instruction which requiers the offset is a multiple of
4. Only fold offset to such instructions if it is a multiple of 4.
Fixes#36723.
"GOARCH=ppc64 GOOS=linux go build -gcflags=all=-d=ssa/check/on std cmd"
passes now.
Change-Id: I67f2a6ac02f0d33d470f68ff54936c289a4c765b
Reviewed-on: https://go-review.googlesource.com/c/go/+/216379
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
The public proxy and checksum database launched with Go 1.13 have been
running smoothly, pkg.go.dev is serving module-aware documentation,
and in 1.14 we have improved the vendoring workflow and finished
Subversion support to reach parity with GOPATH mode for users of those
features, updated documentation (including the “How to Write Go Code”
intro document) and published blog posts describing common modes of
usage, and improved the migration path for existing v2+ modules by
making version resolution less aggressive about "+incompatible" major
versions.
We (always) have more fit-and-finish work to do, but at this point we
believe that module mode will provide a better user experience than
GOPATH mode for most users, including in production use.
Change-Id: I897e0a43e3aebe4c90553c414337a46bfc9c2bef
Reviewed-on: https://go-review.googlesource.com/c/go/+/216317
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
