This change finishes off functionality register ABI for the reflect
package.
Specifically, it implements a call on a MakeFunc'd value by performing
the reverse process that reflect.Value.Call does, using the same ABI
steps. It implements a call on a method value created by reflect by
translating between the method value's ABI to the method's ABI.
Tests are added for both cases.
For #40724.
Change-Id: I302820b61fc0a8f94c5525a002bc02776aef41af
Reviewed-on: https://go-review.googlesource.com/c/go/+/298670
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
cgo_unsafe_args paragma indicates that the function (or its
callee) uses address and offsets to dispatch arguments, which
currently using ABI0 frame layout. Pin them to ABI0.
With this, "GOEXPERIMENT=regabi,regabiargs go run hello.go" works
on Darwin/AMD64.
Change-Id: I3eadd5a3646a9de8fa681fa0a7f46e7cdc217d24
Reviewed-on: https://go-review.googlesource.com/c/go/+/306609
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
asm_windows.s contains dummy references of syscall.loadlibrary
and syscall.getprocaddress, to trigger ABI wrapper/alias
generation to get ABI0 symbols for them. The comment says they
are called from assembly in other packages, but I couldn't find
where. They are defined in Go and only referenced in Go.
CL 179862 removed dummy references in the runtime. This CL
is similar, for the syscall package.
Also, with CL 306609, they will have ABI0 definitions anyway.
Change-Id: I5c7b0efb9762e4ad9c94f0beea8d053d8c8b2cd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/306709
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
"internal/abi" package depends on runtime package and are supposed to
compile with "-+" option.Added internal/abi in the known list of package
that runtime depends on,so that "internal/abi" compiles with "-+".
Fixes#45144
Change-Id: Iad9e2589f2fbd014260cb8ef9f943d2126015fe1
Reviewed-on: https://go-review.googlesource.com/c/go/+/306289
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
It is never used. It is actually CompilationUnit.Lib.Pkg that
contains the package path.
Change-Id: I18189644ea080080868d144e81dfee02f4549133
Reviewed-on: https://go-review.googlesource.com/c/go/+/306710
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Remove a no-longer-used function.
Change-Id: Iad383a9d158d31d4c8b65dd39b71849b44c6b52e
Reviewed-on: https://go-review.googlesource.com/c/go/+/306829
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
The math to invert the input index was wrong.
Fixes#45323
Change-Id: I7c68cac280e8f01a9c806ecb0f195f169267437e
Reviewed-on: https://go-review.googlesource.com/c/go/+/306431
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: David Chase <drchase@google.com>
Currently, gcTestMoveStackOnNextCall doubles the stack allocation on
each call because stack movement always doubles the stack. That's
rather unfortunate if you're doing a bunch of stack movement tests in
a row that don't actually have to grow the stack because you'll
quickly hit the stack size limit even though you're hardly using any
of the stack.
Fix this by adding a special stack poison value for
gcTestMoveStackOnNextCall that newstack recognizes and inhibits the
allocation doubling.
Change-Id: Iace7055a0f33cb48dc97b8f4b46e45304bee832c
Reviewed-on: https://go-review.googlesource.com/c/go/+/306672
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
gcTestMoveStackOnNextCall can fail to move the stack in very rare
cases if there's an unfortunately timed preemption that clobbers the
stack guard. This won't happen multiple times in quick succession, so
make the test just retry a few times.
Change-Id: I247dc0551514e269e7132cee7945291429b0e865
Reviewed-on: https://go-review.googlesource.com/c/go/+/306671
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
In CL 305672 we preserve the pointer type of a store by just not
decomposing it. But this can be problematic when the source of
the store is a direct interface aggregate type (e.g.
struct { x map[int]int }.
In this CL we take a different approach: we preserve the store
type when generating the new store, but also decompose the source.
Fixes#45344.
Change-Id: If5dd496458dee95aa649c6d106b96a6cdcf3e60d
Reviewed-on: https://go-review.googlesource.com/c/go/+/306669
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This change causes finalizers, reflect calls, and Windows syscall
callbacks to assume the register ABI when GOEXPERIMENT=regabiargs is
set. That is, when all Go functions are using the new ABI by default,
these features should assume the new ABI too.
For #40724.
Change-Id: Ie4ee66b8085b692e1ff675f01134c9a4703ae1b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/306571
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Currently when register assignment fails we roll back all the abiParts
that were generated in the process. However, the total number of
registers also increases, but does not get rolled back. The result is
a very incorrect register assignment.
For #40724.
For #44816.
Change-Id: I1934ea5f95f7608ff2067166255099dbc9135e8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/306109
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Includes test.
Long term, need to make the offending code be more in terms
of official types package offsets, instead of duplicating that
logic.
For #40724.
Change-Id: Id33a153f10aed3289cc48d1f99a8e0f6ece9474d
Reviewed-on: https://go-review.googlesource.com/c/go/+/306469
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
For struct like { { a int64; b int16 }; c int32 }, on 64-bit
machines the offset of c is 16, as the inner struct takes 16
bytes because we round up type size to its alignment. Update the
abi package's offset calculation to include this.
We only need to do this for struct type, because for all other
types its size is naturally aligned.
TODO: add a test.
Change-Id: I0c661768cb1ed3cb409b20a88b7e23e059f8e3e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/306449
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
The covers three kinds of uses:
1. Calls of closures from assembly. These are always ABIInternal calls
without wrappers. I went through every indirect call in the runtime
and I think mcall is the only case of assembly calling a Go closure in
a way that's affected by ABIInternal. systemstack also calls a
closure, but it takes no arguments.
2. Calls of Go functions that expect raw ABIInternal pointers. I also
only found one of these: callbackasm1 -> cgocallback on Windows. These
are trickier to find, though.
3. Finally, I found one case on NetBSD where new OS threads were
directly calling the Go runtime entry-point from assembly via a PC,
rather than going through a wrapper. This meant new threads may not
have special registers set up. In this case, a change on all other
OSes had already forced new thread entry to go through an ABI wrapper,
so I just caught NetBSD up with that change.
With this change, I'm able to run a "hello world" with
GOEXPERIMENT=regabi,regabiargs.
For #40724.
Change-Id: I2a6d0e530c4fd4edf13484d923891c6160d683aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/305669
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The logic for constructing calls in (*state).call is based around
targeted experiments with register-based calls. However, when the
register ABI is turned on everywhere, it currently doesn't account for
direct calls to non-ABIInternal functions. This CL adds a much simpler
path to (*state).call when regabiargs is turned on that looks at the
ABI of the target function.
For #40724.
Change-Id: I7f4f5fed8a5ec131bcf1ce5b9d94d45672a304cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/306410
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When regabiargs is enabled, a function's incoming ABI should be
determined solely by the function's own definition ABI (which is
usually ABIInternal, but can be ABI0 for ABI wrappers).
For example, the current code miscompiles ABI0 -> ABIInternal wrappers
when the experiment is enabled because it treats the wrapper itself as
being called as ABIInternal. This causes it to assume the incoming
arguments are already in registers, so usually the wrapper doesn't do
anything with the arguments because it thinks they're already in the
right place. With this fix, these wrappers now correctly load the
arguments from the stack and put them in registers.
For #40724.
Change-Id: Iec784e88ebc55d9e95e830ed7533aa336f3b1ca2
Reviewed-on: https://go-review.googlesource.com/c/go/+/306409
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently the prologue generated for WRAPPER assembly functions uses BX
and DI, but these are argument registers in the register-based calling
convention. Thus, these end up being clobbered when we want to have an
ABIInternal assembly function.
Define REGENTRYTMP0 and REGENTRYTMP1, aliases for the dedicated function
entry scratch registers R12 and R13, and use those instead.
For #40724.
Change-Id: Ica78c4ccc67a757359900a66b56ef28c83d88b3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/303314
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
For in-register arguments, it must have only a single copy of it
present in the function. If there are multiple copies, it confuses
the register allocator, as they are in the same register.
Change-Id: I55cb06746f08aa7c9168026d0f411bce0a9f93f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/306330
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Coupling object resolution to parsing complicates the parsing code, and
is a barrier to improvement. It requires passing around context such as
'lhs' or 'keyOk', and even then sometimes requires guess-work, such as
whether to resolve the key in a composite literal.
In this CL we delay object resolution to a separate pass after the file
parse completes. This makes it easier to see logic of scoping, and
removes state from the parsing code. This can enable subsequent
improvements such as optionally skipping object resolution, aligning the
parser with cmd/compile/internal/syntax, and allowing alternative
parsers to reuse object resolution.
The additional AST traversal appears to slow down parsing by around 4%.
That seems small enough not to worry about, especially since performance
sensitive users may eventually be able to disable object resolution
entirely, saving around 18% off the previous baseline. I'll also mail a
speculative CL showing how we can significantly mitigate the cost of
object resolution by transposing scopes.
For #45104
Change-Id: I98d9143fd77ae29e84ec7c3ae2fdb1139510da37
Reviewed-on: https://go-review.googlesource.com/c/go/+/304455
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This change modifies the system that allows Go functions to be set as
callbacks in various Windows systems to support the new register ABI.
For #40724.
Change-Id: Ie067f9e8a76c96d56177d7aa88f89cbe7223e12e
Reviewed-on: https://go-review.googlesource.com/c/go/+/300113
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
OpArgXXXReg values must be scheduled at the very top, as their
registers need to be live at the beginning before any other use
of the register.
Change-Id: Ic76768bb74da402adbe61db3b2d174ecd3f9fffc
Reviewed-on: https://go-review.googlesource.com/c/go/+/306329
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The existing implementation implicitly reads from the filesystem
instead of using the overlay file data (due to src == nil), so
pass in the overlaid source if we have an overlay for this file.
Fixes#44946
Change-Id: I61ce09d10c5edac1b47332583efdcd3c1241f58a
Reviewed-on: https://go-review.googlesource.com/c/go/+/305071
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is accomplished by checking for simple stores of pointer types
and leaving them alone. The failure case was when a *mspan
(not in heap) stored type was replaced by unsafe.Pointer.
Updates #40724.
Change-Id: I529e1705bf58fb0e64e60d48fd550b3a407e57e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/305672
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
With GOEXPERIMENT=regabidefer, all deferred functions take no
arguments and have no results (their signature is always func()).
Since the signature is fixed, we can replace all of the reflectcalls
in the defer code with direct closure calls.
For #40724.
Change-Id: I3acd6742fe665610608a004c675f473b9d0e65ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/306010
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
The changes between (equivalent, and reviewed) go/types/operand.go
and operand.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker.
The primary differences compared to go/types are:
- use of syntax rather than go/ast package
- explicit mode for untyped nil (rather than relying on the type)
Change-Id: I0c9c1c6153c55cb0550096bd966c9f0f1c766734
Reviewed-on: https://go-review.googlesource.com/c/go/+/305571
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/decl.go
and decl.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker and a minor comment
update.
The primary differences to go/types/decl.go are:
- use of syntax rather than go/ast package
- use of error_ objects to collect follow-on error info
- use of check.conf.Trace rather than global trace flag
- more aggressively marking variables as used in the presence errors
- not using a walkDecl abstraction for const/var/type declarations
Change-Id: I5cf26779c9939b686a3dbaa4d38fdd0c154a92ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/305570
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Change-Id: I78c5744bb01988f1f599569703d83fd21542ac7a
Reviewed-on: https://go-review.googlesource.com/c/go/+/305911
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Change-Id: Iff5074713e1a4484c04b8628fb2611b6d4e154c7
GitHub-Last-Rev: bb0861bbbe
GitHub-Pull-Request: golang/go#45294
Reviewed-on: https://go-review.googlesource.com/c/go/+/305772
Reviewed-by: Ben Shi <powerman1st@163.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Go Bot <gobot@golang.org>
Change-Id: I75d089a7c1c3cdd50e5d2dafdb3386620efff4c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/304454
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
For #45104
For #45221
Change-Id: I8966555f4e8844d5b6766d00d48f7a81868ccf40
Reviewed-on: https://go-review.googlesource.com/c/go/+/304453
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The setting of n.Use for a call node in transformCall() (and previously
in Call()), was not corrrect, since it was trying to use the number of
results of the call, rather than whether the call result was actually
used. We are already setting n.Use to ir.CallUseStmt if the call node is
directly a statement, so we just need to initialize n.Use to
ir.CallExprStmt in Call(), which will get changed to ir.CallUseStmt at
the statement level if it's used as a statement.
Enable inlining of stenciled functions (just disabled for testing,
easier debugging). The above n.Use fix was required for the inlining
to work for two cases.
Change-Id: Ie4ef6cd53fd4b20a4f3be31e629280909a545b7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/305913
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
During substitution of the function type during stenciling, we must set
the Name nodes of the param/result fields of the func type. We get those
name nodes from the substituted Dcl nodes of the PPARAMS and PPARAMOUTs.
But we must check that the names match with the Dcl nodes, so that we
skip any param fields that correspond to unnamed (in) parameters.
Added a few tests to typelist.go by removing a variety of unneeded
function parameter names.
Change-Id: If786961b64549da6f18eeeb5060ea58fab874eb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/305912
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Change-Id: I96170f1ca481b5fe21c85f99e877fa090e4dccc2
Reviewed-on: https://go-review.googlesource.com/c/go/+/304452
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
parsePrimaryExpr has to be careful to resolve identifiers used in
composite expressions when parsing in LHS mode. It missed the literal
type name.
Fixes#45136
Change-Id: I3e12f91e3ef5fdb43faa436cdf1240eb3293fe1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/304451
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Add new tests for object resolution driven by source files with
declarations and uses marked via special comments. This made it easier
to add test coverage while refactoring object resolution for #45104.
Tests are added to a new resolver_test.go file. In a subsequent CL the
resolver.go file will be added, making this choice of file name more
sensible.
For #45104
For #45136
For #45160
Change-Id: I240fccc0de95aa8f2d03e39c77146d4c61f1ef9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/304450
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
In expand_calls, when rewriting OpArg to OpArgIntReg/OpArgFloatReg,
avoid generating duplicates. Otherwise it will confuse the
register allocator: it would think the second occurance clobbers
the first's register, causing it to generate copies, which may
clobber other args.
Change-Id: I4f1dc0519afb77500eae1c0e6ac8745e51f7aa4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/306029
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
exitsyscall0 contains two G variables: _g_ and gp. _g_ is the active G,
g0, while gp is the G to run (which just exited from a syscall).
It is passing _g_ to schedEnabled, which is incorrect; we are about to
execute gp, so that is what we should be checking the schedulability of.
While this is incorrect and should be fixed, I don't think it has ever
caused a problem in practice:
* g0 does not have g.startpc set, so schedEnabled simplifies to
just !sched.disable.user.
* This is correct provided gp is never a system goroutine.
* As far as I know, system goroutines never use entersyscall /
exitsyscall.
As far I can tell, this was a simple copy/paste error from exitsyscall,
where variable _g_ is the G to run.
While we are here, eliminate _g_ entirely, as the one other use is
identical to using gp.
Change-Id: I5df98a34569238b89ab13ff7012cd756fefb10dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/291329
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Handle the case where types can be partially inferred for an
instantiated function that is not immediately called. The key for the
Inferred map is the CallExpr (if inferring types required the function
arguments) or the IndexExpr (if types could be inferred without the
function arguments).
Added new tests for the case where the function isn't immediately called
to typelist.go.
Change-Id: I60f503ad67cd192da2f2002060229efd4930dc39
Reviewed-on: https://go-review.googlesource.com/c/go/+/305909
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Change the amd64 version of 'zerorange' to avoid using RAX/RDI, since
it can be called in a context when one of these registers is live
(contains an incoming parameter).
Updates #40724.
Change-Id: Ibfa2b4e156b876354d4f8bd04eb8773c7056d948
Reviewed-on: https://go-review.googlesource.com/c/go/+/305829
Trust: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
This change guards a call to ast.Inspect with a nil check on the first
argument. This avoids a panic when inspecting a reference to a function
with a nil body. This can only happen when a function body is defined outside Go.
Fixes#42706
Change-Id: I91bc607b24b6224920c24cfd07e76ce7737a98d4
GitHub-Last-Rev: 08072b9ce5
GitHub-Pull-Request: golang/go#43011
Reviewed-on: https://go-review.googlesource.com/c/go/+/275516
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
The correct command to create new go.mod file should be 'go mod init',
not 'go help init'.
Change-Id: I1150621987d989997f8b75e6a13fe96423a11cf3
Reviewed-on: https://go-review.googlesource.com/c/go/+/305289
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Trust: Jay Conrod <jayconrod@google.com>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
old code was always ABI0, new code tracks the default
this may cause some write barrier removals to fail to fire
Updates #40724.
Change-Id: I656bdd5511c5bd6ee6e021999e30d842a6b9f0a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/305671
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When using cgo, some of the frames can be provided by cgoTraceback, a
cgo-provided function to generate C tracebacks. Unlike Go tracebacks,
cgoTraceback has no particular guarantees that it produces valid
tracebacks.
If one of the (invalid) frames happens to put the PC in the alignment
region at the end of a function (filled with int 3's on amd64), then
Frames.Next will find a valid funcInfo for the PC, but pcdatavalue will
panic because PCDATA doesn't cover this PC.
Tolerate this case by doing a non-strict PCDATA lookup. We'll still show
a bogus frame, but at least avoid throwing.
Fixes#44971
Change-Id: I9eed728470d6f264179a7615bd19845c941db78c
Reviewed-on: https://go-review.googlesource.com/c/go/+/301369
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
