delta/go-git.git/src/cmd/internal/objabi, branch dev.cmdgo

[dev.typeparams] runtime,cmd/compile,cmd/link: replace jmpdefer with a loop

2021-08-03T21:05:55+00:00

Currently, deferreturn runs deferred functions by backing up its
return PC to the deferreturn call, and then effectively tail-calling
the deferred function (via jmpdefer). The effect of this is that the
deferred function appears to be called directly from the deferee, and
when it returns, the deferee calls deferreturn again so it can run the
next deferred function if necessary.

This unusual flow control leads to a large number of special cases and
complications all over the tool chain.

This used to be necessary because deferreturn copied the deferred
function's argument frame directly into its caller's frame and then
had to invoke that call as if it had been called from its caller's
frame so it could access it arguments. But now that we've simplified
defer processing so the runtime only deals with argument-less
closures, this approach is no longer necessary.

This CL simplifies all of this by making deferreturn simply call
deferred functions in a loop.

This eliminates the need for jmpdefer, so we can delete a bunch of
per-architecture assembly code.

This eliminates several special cases on Wasm, since it couldn't
support these calling shenanigans directly and thus had to simulate
the loop a different way. Now Wasm can largely work the way the other
platforms do.

This eliminates the per-architecture Ginsnopdefer operation. On PPC64,
this was necessary to reload the TOC pointer after the tail call
(since TOC pointers in general make tail calls impossible). The tail
call is gone, and in the case where we do force a jump to the
deferreturn call when recovering from an open-coded defer, we go
through gogo (via runtime.recovery), which handles the TOC. On other
platforms, we needed a NOP so traceback didn't get confused by seeing
the return to the CALL instruction, rather than the usual return to
the instruction following the CALL instruction. Now we don't inject a
return to the CALL instruction at all, so this NOP is also
unnecessary.

The one potential effect of this is that deferreturn could now appear
in stack traces from deferred functions. However, this could already
happen from open-coded defers, so we've long since marked deferreturn
as a "wrapper" so it gets elided not only from printed stack traces,
but from runtime.Callers*.

This is a retry of CL 337652 because we had to back out its parent.
There are no changes in this version.

Change-Id: I3f54b7fec1d7ccac71cc6cf6835c6a46b7e5fb6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/339397
Trust: Austin Clements 
Run-TryBot: Austin Clements 
TryBot-Result: Go Bot 
Reviewed-by: Cherry Mui

[dev.typeparams] Revert "[dev.typeparams] runtime,cmd/compile,cmd/link: replace jmpdefer with a loop"

2021-07-30T21:51:49+00:00

This reverts CL 227652.

I'm reverting CL 337651 and this builds on top of it.

Change-Id: I03ce363be44c2a3defff2e43e7b1aad83386820d
Reviewed-on: https://go-review.googlesource.com/c/go/+/338709
Trust: Austin Clements 
Run-TryBot: Austin Clements 
TryBot-Result: Go Bot 
Reviewed-by: Cherry Mui

[dev.typeparams] runtime,cmd/compile,cmd/link: replace jmpdefer with a loop

2021-07-30T18:49:44+00:00

Currently, deferreturn runs deferred functions by backing up its
return PC to the deferreturn call, and then effectively tail-calling
the deferred function (via jmpdefer). The effect of this is that the
deferred function appears to be called directly from the deferee, and
when it returns, the deferee calls deferreturn again so it can run the
next deferred function if necessary.

This unusual flow control leads to a large number of special cases and
complications all over the tool chain.

This used to be necessary because deferreturn copied the deferred
function's argument frame directly into its caller's frame and then
had to invoke that call as if it had been called from its caller's
frame so it could access it arguments. But now that we've simplified
defer processing so the runtime only deals with argument-less
closures, this approach is no longer necessary.

This CL simplifies all of this by making deferreturn simply call
deferred functions in a loop.

This eliminates the need for jmpdefer, so we can delete a bunch of
per-architecture assembly code.

This eliminates several special cases on Wasm, since it couldn't
support these calling shenanigans directly and thus had to simulate
the loop a different way. Now Wasm can largely work the way the other
platforms do.

This eliminates the per-architecture Ginsnopdefer operation. On PPC64,
this was necessary to reload the TOC pointer after the tail call
(since TOC pointers in general make tail calls impossible). The tail
call is gone, and in the case where we do force a jump to the
deferreturn call when recovering from an open-coded defer, we go
through gogo (via runtime.recovery), which handles the TOC. On other
platforms, we needed a NOP so traceback didn't get confused by seeing
the return to the CALL instruction, rather than the usual return to
the instruction following the CALL instruction. Now we don't inject a
return to the CALL instruction at all, so this NOP is also
unnecessary.

The one potential effect of this is that deferreturn could now appear
in stack traces from deferred functions. However, this could already
happen from open-coded defers, so we've long since marked deferreturn
as a "wrapper" so it gets elided not only from printed stack traces,
but from runtime.Callers*.

Change-Id: Ie9f700cd3fb774f498c9edce363772a868407bf7
Reviewed-on: https://go-review.googlesource.com/c/go/+/337652
Trust: Austin Clements 
Run-TryBot: Austin Clements 
TryBot-Result: Go Bot 
Reviewed-by: Cherry Mui

[dev.typeparams] runtime: remove variadic defer/go calls

2021-06-08T19:46:10+00:00

Now that defer/go wrapping is used, deferred/go'd functions are
always argumentless. Remove the code handling arguments.

This CL is mostly removing the fallback code path. There are more
cleanups to be done, in later CLs.

Change-Id: I87bfd3fb2d759fbeb6487b8125c0f6992863d6e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/325915
Trust: Cherry Mui 
Run-TryBot: Cherry Mui 
TryBot-Result: Go Bot 
Reviewed-by: Michael Knyszek

cmd/compile: always include underlying type for map types

2021-05-24T17:43:50+00:00

This is a different fix for #37716.

Should help make the fix for #46283 easier, since we will no longer
need to keep compiler-generated hash functions and the runtime
hash function in sync.

Change-Id: I84cb93144e425dcd03afc552b5fbd0f2d2cc6d39
Reviewed-on: https://go-review.googlesource.com/c/go/+/322150
Trust: Keith Randall 
Run-TryBot: Keith Randall 
TryBot-Result: Go Bot 
Reviewed-by: Cherry Mui

syscall, etc.: use abi.FuncPCABI0 for libc syscall wrappers

2021-04-26T15:52:34+00:00

In CL 288092 we made Darwin syscall wrappers as ABIInternal, so
their addresses taken from Go using funcPC are the actual function
entries, not the wrappers.

As we introduced internal/abi.FuncPCABIxxx intrinsics, use that.
And change the assembly functions back to ABI0.

Do it on OpenBSD as well, as OpenBSD and Darwin share code
generator.

Change-Id: I408120795f7fc826637c867394248f8f373906bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/313230
Trust: Cherry Zhang 
Run-TryBot: Cherry Zhang 
TryBot-Result: Go Bot 
Reviewed-by: Than McIntosh 
Reviewed-by: Michael Knyszek

cmd/compile, runtime: add metadata for argument printing in traceback

2021-04-22T17:47:59+00:00

Currently, when the runtime printing a stack track (at panic, or
when runtime.Stack is called), it prints the function arguments
as words in memory. With a register-based calling convention,
the layout of argument area of the memory changes, so the
printing also needs to change. In particular, the memory order
and the syntax order of the arguments may differ. To address
that, this CL lets the compiler to emit some metadata about the
memory layout of the arguments, and the runtime will use this
information to print arguments in syntax order.

Previously we print the memory contents of the results along with
the arguments. The results are likely uninitialized when the
traceback is taken, so that information is rarely useful. Also,
with a register-based calling convention the results may not
have corresponding locations in memory. This CL changes it to not
print results.

Previously the runtime simply prints the memory contents as
pointer-sized words. With a register-based calling convention,
as the layout changes, arguments that were packed in one word
may no longer be in one word. Also, as the spill slots are not
always initialized, it is possible that some part of a word
contains useful informationwhile the rest contains garbage.
Instead of letting the runtime recreating the ABI0 layout and
print them as words, we now print each component separately.
Aggregate-typed argument/component is surrounded by "{}".

For example, for a function

F(int, [3]byte, byte) int

when called as F(1, [3]byte{2, 3, 4}, 5), it used to print

F(0x1, 0x5040302, 0xXXXXXXXX) // assuming little endian, 0xXXXXXXXX is uninitilized result

Now prints

F(0x1, {0x2, 0x3, 0x4}, 0x5).

Note: the liveness tracking of the spill splots has not been
implemented in this CL. Currently the runtime just assumes all
the slots are live and print them all.

Increase binary sizes by ~1.5%.

old new
hello (println) 1171328 1187712 (+1.4%)
hello (fmt) 1877024 1901600 (+1.3%)
cmd/compile 22326928 22662800 (+1.5%)
cmd/go 13505024 13726208 (+1.6%)

Updates #40724.

Change-Id: I351e0bf497f99bdbb3f91df2fb17e3c2c5c316dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/304470
Trust: Cherry Zhang
Run-TryBot: Cherry Zhang
TryBot-Result: Go Bot
Reviewed-by: Michael Knyszek

internal/buildcfg: move build configuration out of cmd/internal/objabi

2021-04-16T19:20:53+00:00

The go/build package needs access to this configuration,
so move it into a new package available to the standard library.

Change-Id: I868a94148b52350c76116451f4ad9191246adcff
Reviewed-on: https://go-review.googlesource.com/c/go/+/310731
Trust: Russ Cox 
Run-TryBot: Russ Cox 
Reviewed-by: Austin Clements 
Reviewed-by: Jay Conrod

cmd/internal/objabi,test: use correct GOEXPERIMENT build tags in test/run.go

2021-04-16T03:16:55+00:00

Currently, run.go sets GOEXPERIMENT build tags based on the
*difference* from the baseline experiment configuration, rather than
the absolute experiment configuration. This differs from cmd/go. As a
result, if we set a baseline configuration and don't override it with
a GOEXPERIMENT setting, run.go won't set any GOEXPERIMENT build tags,
instead of setting the tags corresponding to the baseline
configuration.

Fix this by making compile -V=goexperiment produce the full
GOEXPERIMENT configuration, which run.go can then use to set exactly
the right set of build tags.

For #40724.

Change-Id: Ieda6ea62f1a1fabbe8d749d6d09c198fd5ca8377
Reviewed-on: https://go-review.googlesource.com/c/go/+/310171
Trust: Austin Clements 
Run-TryBot: Austin Clements 
TryBot-Result: Go Bot 
Reviewed-by: Cherry Zhang

internal/goexperiment: move baseline configuration to objabi

2021-04-16T03:16:11+00:00

We need to adjust baseline experiment configuration based on the
configured GOOS and GOARCH, so it can't live in goexperiment. Move it
to objabi.

Change-Id: I65f4ce56902c6c1a82735050773c58f2d1320cc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/310169
Trust: Austin Clements 
Run-TryBot: Austin Clements 
TryBot-Result: Go Bot 
Reviewed-by: Russ Cox